[Errno 36] File name too long on eCryptfs

[juandiazq]

Filesystem: EXT4
OS: Ubuntu Linux 14.04 LTS
youtube-dl --version: 2015.06.04.1
When I try to download a Vimeo video:

youtube-dl --ignore-errors --restrict-filenames https://vimeo.com/80352108

I got the following error:

ERROR: unable to open for writing: [Errno 36] File name too long: ...

[dstftw]

Post the full output of youtube-dl when run with --verbose option.

[juandiazq]

Command:

youtube-dl --verbose --ignore-errors --restrict-filenames https://vimeo.com/80352108

Output:

[debug] System config: []
[debug] User config: []
[debug] Command-line args: [u'--verbose', u'--ignore-errors', u'--restrict-filenames', u'https://vimeo.com/80352108']
[debug] Encodings: locale UTF-8, fs UTF-8, out UTF-8, pref UTF-8
[debug] youtube-dl version 2015.06.04.1
[debug] Python version 2.7.6 - Linux-4.0.4-x86_64-with-Ubuntu-14.04-trusty
[debug] exe versions: avconv 9.18-6, avprobe 9.18-6, ffmpeg 2.6.3, ffprobe 2.6.3, rtmpdump 2.4
[debug] Proxy map: {'no': 'localhost,127.0.0.0/8,::1'}
[vimeo] 80352108: Downloading webpage
[vimeo] 80352108: Extracting information
[vimeo] 80352108: Downloading webpage
[debug] Invoking downloader on u'https://pdlvimeocdn-a.akamaihd.net/19466/858/207887776.mp4?token2=1433607436_7bc3e3622d36ab86380807a519b67bb7&aksessionid=021f61e14dcae728'
ERROR: unable to open for writing: [Errno 36] File name too long: 'Oliver_Stone_-_La_historia_no_contada_de_Estados_Unidos_09_-_Bush_y_Clinton_-_El_triunfalismo_americano_y_el_nuevo_orden_mundial-80352108.mp4.part'
Traceback (most recent call last):
  File "/usr/local/bin/youtube-dl/youtube_dl/downloader/http.py", line 155, in real_download
    (stream, tmpfilename) = sanitize_open(tmpfilename, open_mode)
  File "/usr/local/bin/youtube-dl/youtube_dl/utils.py", line 249, in sanitize_open
    stream = open(encodeFilename(filename), open_mode)
IOError: [Errno 36] File name too long: 'Oliver_Stone_-_La_historia_no_contada_de_Estados_Unidos_09_-_Bush_y_Clinton_-_El_triunfalismo_americano_y_el_nuevo_orden_mundial-80352108.mp4.part'

[dstftw]

Works perfectly for me under ext4. It's not even close to filename length limit (255).

[juandiazq]

I will check the ext4 mount options.

[dstftw]

What's the length of the full path you run youtube-dl in?

[juandiazq]

/usr/local/bin/youtube-dl

[dstftw]

I mean the location where you download this file.

[juandiazq]

/home/user/Descargas/OliverStone

[dstftw]

What's the output of getconf NAME_MAX /home/user/Descargas/OliverStone && getconf PATH_MAX /home/user/Descargas/OliverStone?

[juandiazq]

NAME_MAX=143
PATH_MAX=4096

I didn't mention that my /home/user folder is encrypted with ecryptfs. I've just found the answer in this bug that will not be fixed in Ubuntu: https://bugs.launchpad.net/ecryptfs/+bug/1018050. Anyway, Should the filename be truncated?

[dstftw]

NAME_MAX=143 that's it.
Only if we truncate or shorten manually in youtube-dl before writing.

[juandiazq]

A workaround is to download in /tmp and then move the file to the dest folder with a shorter name or use the youtube-dl [...] -o <filename> option.

[nicolas-raoul]

It is not only for Vimeo, but for all services.
I sometimes get this error. I believe it is due to a Linux encrypted home. Encrypted home makes the maximum filename size much shorter.
Running cd /tmp before running youtube-dl works as a workaround.
A better solution would be to first check the maximum filename size, or at least, if it fails try again with shorter filenames.

[yuriw]

Bug is still here, running cd /tmp helped thx, but permanent fix would be very nice to have.

[someguy736]

Long path names are also a problem on Windows. Using symbolic links or juncture points is also a way to fix the issue (so you don't have to add some messy movement operation) but it makes file structures cluttered.

Please add support for longer file names or have some way to truncate all or part of the string in the options.

EXAMPLE

--output 'C:\longafname\look\how\long\i\keep\growing\%(uploader)s\%(title)st20\%(title)st20-%(id)s.%(ext)s'

Where t is the truncate delimiter and 20 is the number of characters before the string gets truncated.

[sleeksorrow]

Since Twitter increased their char limit from 140 to 280 chars, this service is also affected when saving on eCryptfs

[comrat]

Hello everyone!
I've fix it (sort of kludge) with setting limit for output file name in my fork in corresponded branch
Hope it helps for somebody

[shillshocked]

Your fork didn't fix the problem for me.

[comrat]

@shillshocked can you provide your link which didn't work?
You can also create an issue in my fork or write to me poberyaa@gmail.com

[thomasrussellmurphy]

I have also recently been experiencing this with Twitter video sources. MacOS 10.14.6, downloading to /Users/thomasrussellmurphy/Downloads, typically. The immediate workaround is to re-run with --id, producing a low-informative-value output file name, but successfully acquiring the file. I can provide the most recent problem link, if necessary.

[chovy]

I want to just automatically truncate long filenames.

[chovy]

this doesnt' work: -o '%(title)st20'

[ajj8]

@chovy This output format fixes it:

-o %(title).100s-%(id)s.%(ext)s

Replace the 100 with whatever you want, a character limit of 220 works good for me on Windows. This still should be implemented in to youtube-dl, though.

[in-in]

I think the limit depends not on the number of characters, but on the number of bytes.

echo -n "one" | wc --bytes  # 3

# not latin characters
echo -n "раз" | wc --bytes  # 6

In my case(Linux), the limit is 255 bytes for the entire path(filename).

[msj2]

Issue is also due to Unicode Support angle. :)
am trying to download this
https://twitter.com/i/status/1249722477577564162

Steps:

1. cd /tmp
2. youtube-dl --verbose https://twitter.com/i/status/1249722477577564162

Output
[debug] System config: []
[debug] User config: []
[debug] Custom config: []
[debug] Command-line args: [u'--verbose', u'https://twitter.com/i/status/1249722477577564162']
[debug] Encodings: locale UTF-8, fs UTF-8, out UTF-8, pref UTF-8
[debug] youtube-dl version 2020.03.08
[debug] Python version 2.7.12 (CPython) - Linux-4.4.0-140-generic-x86_64-with-Ubuntu-16.04-xenial
[debug] exe versions: ffmpeg 2.8.15, ffprobe 2.8.15
[debug] Proxy map: {}
[twitter] 1249722477577564162: Downloading guest token
[twitter] 1249722477577564162: Downloading JSON metadata
[twitter] 1249722477577564162: Downloading m3u8 information
[debug] Default format spec: bestvideo+bestaudio/best
[debug] Invoking downloader on u'https://video.twimg.com/ext_tw_video/1249722345406656513/pu/vid/320x180/T0NEatsKJCrzxJSc.mp4?tag=10'
ERROR: unable to open for writing: [Errno 36] File name too long: 'Kumar Bhanu KS ### \xf0\x9f\x87\xae\xf0\x9f\x87\xb3 - Sri Sri Mahasannidhanam \xf0\x9f\x99\x8f #SringeriJagadGuru Beautifully explained in the below Upanyasa how one must use his money; please watch Can you find anyone who is not greed for money No man will not be greedy for money, and if he earns Rs.10, he thinks-1249722477577564162.mp4.part'
Traceback (most recent call last):
File "/usr/local/lib/python2.7/dist-packages/youtube_dl/downloader/http.py", line 250, in download
ctx.tmpfilename, ctx.open_mode)
File "/usr/local/lib/python2.7/dist-packages/youtube_dl/utils.py", line 2046, in sanitize_open
stream = open(encodeFilename(filename), open_mode)
IOError: [Errno 36] File name too long: 'Kumar Bhanu KS \xf0\x9f\x87\xae\xf0\x9f\x87\xb3 - Sri Sri Mahasannidhanam \xf0\x9f\x99\x8f #SringeriJagadGuru Beautifully explained in the below Upanyasa how one must use his money; please watch Can you find anyone who is not greed for money No man will not be greedy for money, and if he earns Rs.10, he thinks-1249722477577564162.mp4.part'

am wondering, if these could help...

1. Encoding these to Unicode \xf0\x9f\x87\xae\xf0\x9f\x87\xb3 - Sri Sri Mahasannidhanam \xf0\x9f\x99\x8f
2. Renaming the output file name to have first 250 Letters & 5 digit counter

[mayeaux]

+1 for automatic truncating

[daniells]

This issue affects a large number of twitter videos as youtube-dl attempts to use the full tweet as the filename. EXT4, NTFS, and HFS support only 255 characters per filename, but the current max-tweet is 280 characters.

Truncating filenames to 255 characters (including extension) should fix "File name too long" in all conceivable use cases.