Filename length limits on linux?
See the Wikipedia page about file systems comparison, especially in column Maximum filename length.
Here are some filename length limits in popular file systems:
BTRFS 255 bytes exFAT 255 UTF-16 characters ext2 255 bytes ext3 255 bytes ext3cow 255 bytes ext4 255 bytes FAT32 8.3 (255 UCS-2 code units with VFAT LFNs) NTFS 255 characters XFS 255 bytes @rahmanisback that’s right for filename limits, while path limits are usually defined by the OS, not FS (except for some strange FSes like iso or ntfs), and, on linux, are 4K
I’m shocked by these limits. Files per directory is unlimited, 4 billion files per volume, file sizes into the terabytes, volume sizes go to exabytes but we have a stupid limit of 255 bytes for file names?
It should also be mentioned that if you layer eCryptFS with filename encryption on top of these file systems (as installed in Ubuntu with encrypted home dir option) the effective maximum filename length will only be 143 characters. See: unix.stackexchange.com/a/32834/47938
I’ve read here that path length limit is in system headers. File name length limit is there too. On my system it’s file:
/usr/src/linux-headers-2.6.38-10/include/linux/limits.h #define NAME_MAX 255 /* # chars in a file name */ #define PATH_MAX 4096 /* # chars in a path name including nul */ Sorry, but I’am new here an can’t even comment, save vote. The previous answer (by sfp) should be upped, as it answers the question completely, while the others are partially off. Again, sorry for going besides the rules, but I can’t be quiet when the best answer is at the bottom.
@DavidBalažic: Although true, PATH_MAX under linux is just a guideline, most of the underlying file systems do not have a limitation. This makes it hard to reference paths that greater than that size. I usually use «chunks» of PATH_MAX as a size.
I refer to other answers, please upvote them.
Are there any filename or path length limits on Linux?
Yes, filename and pathname lengths are limited by :
To dynamically get these properties:
- Use functions pathconf and fpathconf as proposed by Michael Aaron Safyan
- Create a filename (or pathname) longer and longer as explained by dogbane
- Use the command getconf as proposed by tim that is also available on Linux:
$ getconf NAME_MAX /mnt/sda2/ 255 $ getconf PATH_MAX /mnt/sda3/ 4096 And for the sake of saving time (and anchoring it to memory):
ext2, ext3, ext4, zfs: no pathname limits; 255 bytes filename limit.
Most programs are limited with absolute paths to PATH_MAX = 4096 , though. That can be worked around if your program is able to use relative paths and you change your working directory first.
It’s because various POSIX APIs such as getcwd and realpath (which you can reimplement in userspace code by reading the metadata for . and then changing to .. and repeating until you hit the filesystem root) rely on PATH_MAX . (Source)
Yes, however, awfully lot of misc library code is prone to break if your code changes current directory at will. A well made code doesn’t break but most of the existing code is not well made.
Those are file system name lengths. «linux» itself has some too. For instance, from bits/stdio_lim.h:
So since the extX filesystems have a lower filename limit than what’s defined in the kernel, you wouldn’t ever hit that limit, unless it also encompases pathnames, right?
that’s what it looks like to me. There’s also PATH_MAX for the path, which is 4096, so it would be hit before the «unlimited» path size on the exts. I’m not sure how the OS resolves its own internal restrictions and those of the FS, never had my arms in that deep. interesting question though.
4096 characters is a helluva path name. I’m sure it could be raised with a recompile, but honestly, /why would you need pathnames that long?/
I’m not sure you would need it or not. I view it more as a protection against malicious or negligent programs (I could easily see a script that behaves poorly and begins creating the same dir recursively. Actually, I’ve made that script, but it was redirecting a web site, not creating dirs. ).
There is no way to determine the maximum length of paths on Linux in a portable way. On my system:
$ getconf PATH_MAX / 4096 $ getconf _POSIX_PATH_MAX / 4096 But I can easily create paths much longer than 4096 characters. Instead see PATH_MAX as a lower bound. You are guaranteed to be able to create paths this long, but you might also be able to create much longer ones.
A simple portable way to find the maximum length empirically is to write a program which creates longer and longer directory chains, and see where it fails. You won’t know exactly why it fails (though you would hope for a suggestive human-readable error message) but you’ll know how far you can safely go. Remember to check for both individual directory length, relative pathname length, and absolute pathname length.
Also, e.g. the Python os.pathconf() module will have some answers; if the Python port is any good, they should be reasonable.
You can’t because some filesystems don’t impose any limits. It would sooner fail with an out of memory error which any program would have a hard time recovering from.
This is the correct answer, except this is due to @BjörnLindqvist comment. PATH_MAX is just a guideline, and 99% of files will probably be within that limit.
Что делать с максимальной длинной пути в линуксе при копировании файлов с винды?
При копировании файлов с винды не редко сталкивался сталкивался с ошибками о максимальной длине пути.
Длина имени файла = 255 байт?
Согласно этому треду максимальная длина пути Length of pathname is 4095 chars. (limit of kernel) . Можно ли её расширить? И действительно ли все эти 4095 символом можно использовать?
Причём сталкивался с этим не только при копировании файлов с виндовых компов по сети (особенно часто url-файлы имеют очень длинный путь), но и при загрузке торрентов. Предвкушаю проблемы с переносом профилей или файловых помоек винды на самбу, а также проблемы с rsync и бекапами.
И действительно ли все эти 4095 символом можно использовать?
Да, можно. Только учти, что это 4095 ASCII символов. А имена файлов закодированы в UTF-8 скорее всего. А там, например, русские буквы занимают 2 байта.
А можно тогда расширить эту структуру? Или тогда нужно будет и glibc пересобрать?
Ограничение в 4095 байт вряд ли тебя как-то коснётся, так как в Windows эффективное ограничение на длину пути — 260 символов. Конечно, Windows может и больше, но очень много сторонних программ имеют ограничение именно в 260 символов.
Что тебя коснётся, так это разность между символом и байтом. В Linux большинство ФС имеют ограничение на длину имени в 255 байт, тогда как в Windows это 255 символов. Если используется многобайтная кодировка вроде UTF-8, символов в имя влезает меньше, и это как раз вызывает проблемы.
Часто можно встретить мнение, что ограничение в 255 байт зашито в VFS, но это не правда (по крайней мере, сейчас). Ограничение вшито в сами ФС. Я смотрел на эту тему код ext4 и reiserfs. В ext4 под длину выделен один байт, так что больше 255 позиций там сделать точно нельзя. В reiserfs принципиальное ограничение — размер блока минус что-то там, то есть чуть больше 4000 байт. Но и там просто константой длина ограничена 255 байтами. В FUSE ограничение — 1024 байта, поэтому можно через неё подцепить ntfs-3g и писать туда. Можно ещё сделать прокси-ФС на FUSE, отображающую длинные имена в более короткие. Я так пробовал сделать, оно даже работало, но довольно криво — не доделал.
Спасибо за столь подробый пост. Можете уточнить про вариант с FUSE? И можно ли просто с iocharset и charset/codepage примонтировать? Есть ли ФС, у которых нет таких проблем (кроме ntfs-3g)? У ядерного драйвера NTFS нет проблем?
И Вы, случаем, не в курсе, что делает опция монтирования uni_xlat?
Можете уточнить про вариант с FUSE?
Так как в случае с FUSE можно писать свою ФС, ограничения в 255 байт делать никто не заставляет. Я делал вот так: https://github.com/i-rinat/insecure, оно хранит имена в SQLite. Но предупреждаю, этот код реально кривой.
Ответ на каждый из остальных вопросов: «не знаю».
What is the maximum length of a file path in Ubuntu?
Having used Windows systems for a long time, I know that at a certain point, an error window can appear when files and folder names become too long. This happened to me when I tried to backup files with SFTP from a server to a folder in (for example):
D:(Windows drive partition)/Temporary/Projects/2015-06/Websites/Guitar-Site/Images/Logos/Manufacturers/Instruments/Basses/(long file name).png As you can see, I tend to build very specified folder paths sometimes and if a file name happens to be long as well, NTFS might not be able to save it this way. I’m currently worrying about my physical backups, as the folder path on my backup drive will add /backups/(drive name)/. to all file paths. Is there any such limit (or a similar one) in ext4/Ubuntu that I would have to look out for?
Answered over on ServerFault: 4k. It’s an OS limit, not an FS limit. serverfault.com/questions/9546/…
4 Answers 4
The max filename length is 255 bytes. Found in the wiki page for ext4.
And a maximum path of 4096 characters. Found in this Unix&Linux SE Question.
Although, I did find this wiki article that does not specify a max file path in ext4.
Hi jtoscarson, thanks for your answer. I could probably try to look this up, but would you care to explain what a length of «255 bytes» means? I assume that not all characters necessarily use up 8 bits, so that would be more than 255 characters in total, I assume? Or maybe less, considering different charactersets could be used.
Generally speaking a single character is one byte. I didn’t look for the documentation, but here is a simple test: jtoscarson@Tylers-Ubuntu:~$ echo «123abc» | wc -c 7 jtoscarson@Tylers-Ubuntu:~$ echo «123abc» | wc -m 7 The -m is counting characters and the -c is counting bytes. The reason why it is 7 instead of 6 is the end of line character which is not printed. So the total characters in the filename is going to be 255.
Using UTF-8 locale returns 4 for echo -n «💩» | wc -c . Creating a filename called with that name would take 4 bytes despite the fact that this filename is 1 grapheme long. A «character» is not clearly defined concept (usually it means byte, grapheme or UNICODE code point).
On encrypted filesystems the max filename length is 143 bytes. To decide whether a filename is short enough you can find his byte length in Python with len(filename.encode()) .
Max filename length is dynamic and depends on mount options (e.g. use of encfs or ecryptfs may cause values less than 255). The correct value can be queried with getconf NAME_MAX /path/to/directory
As @sergiy-kolodyazhnyy said, the maximum filename length will depend on the filesystem and the vast majority limit filename lengths to 255 bytes.
A notable omission from his chart is optical media. While UDF and the Rock Ridge extensions have the same 255-character limit for filenames, ISO9660 without Rock Ridge and Joliet both have much stricter limits that you may actually run up against if you’re doing something like backing up youtube-dl downloads.
Joliet filenames are limited to either 64 UTF-16 codepoints or 103 of them if your disc-mastering program has an option to break from the spec in ways which seem to cause no harm in practice.
Likewise, ISO 9660 Levels 2 & 3, without the Rock Ridge extensions, are limited to filenames of either 31 characters or 37 if you’re playing fast and loose with the spec.
ISO 9660:1999, which is supported by genisoimage but not by frontends like K3b, has a limit of either 207 bytes (without Rock Ridge) or 197 bytes (with Rock Ridge).
(Source: The genisoimage manpage)
As for the maximum path length, that’s a big misconception. There isn’t one for most Linux filesystems.
There’s a constant named PATH_MAX , but it’s only the maximum for certain POSIX APIs, which you can work around.
The only consequential exceptions to this «no limit on path length» convention are FAT32 and exFAT (32,760 Unicode characters), NTFS and ReFS (32,767 Unicode characters), UDF (1,023 bytes), and ISO 9660 (unclear, but I’ve seen it stated as 180, 207, 212, or 222 bytes).
This can be easily demonstrated by running this small Python program and then exploring the resulting directories.
import os for X in range(20): os.mkdir('x' * 255) os.chdir('x' * 255) My bash , which displays the whole path in the prompt, will have trouble with it. However my zsh , which displays only the current folder in the prompt will have no trouble and even has a pwd builtin that can display the entire 5000+-byte path without issue.