Limit on file name length in bash [closed]
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
- Is there a limit on the number of characters in the absolute path name of a file?
- Is there a limit on the number of characters for the filename (without extension) only?
If so, what might these limits be? How can I access them in case they are system specific?
This smells so much like homework. but in the end it belongs on ServerFault, SuperUser or Unix&Linux.
@KarolyHorvath I was only trying in my code to code information on how data were generated into the filename, but failed to write im_syn_profile_BT,Radar94Z,_to_IWC,_chans1,2,3,4,5,6,7,8,9,10,11,12,_noise1.000000e-01,1.000000e-01,1.000000e-01,1.000000e-01,1.000000e-01,1.000000e-01,1.000000e-01,1.000000e-01,1.000000e-01,1.000000e-01,1.000000e-01,1.000000e-01,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,_0.mat 🙁
9 Answers 9
It depends very much on the filesystem. For the ext FS (currently the most used on Linux):
The extension is not something the FS is aware of, it 255 bytes, extension included (you can have file names without any extensions).
Here is a more exhaustive list of these limits, per FS.
There can also be extensions to your file system that can change your maximum length as well. For example, eCryptFS which uses part of the lower file name to keep metadata and limits the file name to a maximum length of 143 characters. See Ubuntu eCryptFS launchpad entry.
Какой максимальной длины может быть имя файла в Linux?
Есть ли ограничение на длину имен файлов и директорий в Linux? Можно ли создать файл с именем, в котором будет 1000 символов?
Да, такое ограничение существует.
Если попробовать создать файл с очень длинным именем, то возникнет ошибка:
touch IktomiisaspiderfairyHewearsbrowndeerskinlegginswithlongsoftfringesoneithersideandtinybeadedmoccasinsonhisfeetHislongblackhairispartedinthemiddleandwrappedwithredredbandsEachroundbraidhangsoverasmallbrownearandfallsforwardoverhisshouldersHeevenpaintshisfunnyfacewithredandyellowanddrawsbigblackringsaroundhiseyesHewearsadeerskinjacketwithbrightcoloredbeadssewedtightlyonitIktomidresseslikearealDakotabraveIntruthhispaintanddeerskinsarethebestpartofhimifeverdressispartofmanorfairy touch: невозможно выполнить touch для 'IktomiisaspiderfairyHewearsbrowndeerskinlegginswithlongsoftfringesoneithersideandtinybeadedmoccasinsonhisfeetHislongblackhairispartedinthemiddleandwrappedwithredredbandsEachroundbraidhangsoverasmallbrownearandfallsforwardoverhisshouldersHeevenpaintshisfunnyfacewithredandyellowanddrawsbigblackringsaroundhiseyesHewearsadeerskinjacketwithbrightcoloredbeadssewedtightlyonitIktomidresseslikearealDakotabraveIntruthhispaintanddeerskinsarethebestpartofhimifeverdressispartofmanorfairy': Слишком длинное имя файла
В Linux максимальная длина имени файла или директории составляет 255 байт.
Но нужно знать, что каждый символ английского алфавита занимает 1 байт. То есть длина в 255 байт эквивалентна 255 символам английского алфавита.
А каждая кириллическая буква занимает 2 байта. Получается, что если создавать файл только из букв русского алфавита, то максимальная длина составит всего 256/2=127,5 или просто 127 символов.
Например, можно создать вот такой файл:
touch ЖилибылипузырьсоломинкаилапотьПошлионивлесдроварубитьДошлидорекиинезнаюткакчерезрекуперейтиЛапотьговоритпузырюПузырьдавайнатебе
Как увеличить лимит 255 символов на имя файла
Я так понимаю, что это системное ограничение VFS и у всех файловых систем, даже тех, которые в принципе поддерживают больше символов в имени файла, например, в ReiserFS длина в Linux все-равно не более 255 символов.
Есть ли смысл патчить ядро и что именно там надо патчить, чтобы увеличить это число, кто-нибудь пробовал это делать?
А программы такой финт ушами нормально переварят?
Ну, если каждая программа ещё и длину имент файла проверять будет.
Ну, если каждая программа ещё и длину имент файла проверять будет.
А в программе подобного лимита быть не может, что она такие файлы просто-напросто не сможет прочитать?
Вангую что ограничение в 255 не только и даже не столько в ядре как скорее всего в системных библиотеках.
длина в Linux все-равно не более 255 символов
Ибо нефиг. А тебе зачем, торенты качаешь?
Есть ли смысл патчить ядро и что именно там надо патчить
Что сделал несколько лет назад на своём ноуте:
1. Увеличил в ядре (include/uapi/linux/limits.h) NAME_MAX и XATTR_NAME_MAX до 1023.
2. Для ReiserFS увеличил REISERFS_MAX_NAME(block_size) до 1023. (Пользуюсь постоянно, с проблемами не сталкивался.)
3. Для Btrfs увеличил BTRFS_NAME_LEN до 1023 (в ядре) и в btrfs-progs. (Опыта с этой ФС имею мало, но вроде всё нормально.)
4. Reiser4 работает как надо в этой части без необходимости подкручивания чего-либо. (Жаль, что не в ядре. Но опыта тоже немного.)
5. Это всё, что можно относительно просто сделать — остальные ФС (включая XFS и F2FS), насколько могу судить по своим неудачным потыткам и беглому просмотру их кода, просто так не изменить. Особенно удивили NILFS и F2FS, запиливаемые азиатами, странно, что их эта проблема не интересует.
6. Ну и напоследок увеличил в CUPS значение IPP_MAX_NAME до 1024.
PS. Было бы крайне интересно получить опровержение по п.5. Кстати, мои попытки по ним совсем свежие.
Спасибо за инфу тебе и анонимусу ниже
Научные публикации храню. Много. Не переименовывать же их.
Почему бы и нет — используй хэш вместо имени и каталог названий. Можно тупо файлик хэш -> название, можно БД замутить.
странно, что их эта проблема не интересует
Дык у них символы хоть и длинные, зато слова короткие. Даже если использовать слоговое письмо, а не иероглифы, выйдет наверное короче чем русский текст. Не говоря уже про всякие ромадзи, или пиньинь.
В дефолтном ядре для FUSE ограничение стоит не 255, а 1024 (или 1023?) байта. Поэтому, например, для ntfs-3g, имена могут быть длиннее.
запиливаемые азиатами, странно, что их эта проблема не интересует.
Как раз нет: один иероглиф занимает много байт, но и сам значит сильно много.
у них символы хоть и длинные, зато слова короткие.
Точно. Значит можно и не надеяться, что в этих ФС появится поддержка очень длинных имён.
Беглый взгляд показал, что таки да, он может выползти немало откуда.
Спасибо, интересно, что первая ссылка там как раз на ЛОР =)) Но это для своего дистра надо вручную патчить ядро, glibc и btrfs, но тем не менее. Проблема серьезнее чем думал, хотя и есть варианты решения.
Народ, ну и пропихните это всё в соответствующие проекты, у кого что получилось, а мы поддержим это всё поддакиванием в списках рассылки соотв. проектов. Только ссылки сюда скиньте, чтобы знать куда ходить.
Подписываюсь на тему. Не знаю зачем мне оно надо, но оно надо!
Народ, ну и пропихните это всё в соответствующие проекты
У Линуса ЧСВ непропихивальное теперь, трудно будет. Да что там мы — Ханс не смог.
Так уже пытались? ну поросёнок.
ну и пропихните это всё в соответствующие проекты
ReiserFS, Reiser4 и Btrfs вполне себе работают (требуют только изменения константы, а в случае Reiser4 не надо и этого делать). Спасибо за это Гансу (Мейсон ведь тоже у него работал, так что очень условно можно сказать, что корни одни). Отдельное спасибо тем, кто поддерживает Reiser* в актуальном состоянии и даже развивает.
Изменить константу, наложить патчи и пересобрать — это всё относительно просто.
А вот со всеми остальными линуксовыми файлухами всё намного сложнее — надо менять структуры хранения данных (мне бы очень хотелось ошибаться в этом). В условиях, когда это не надо их авторам, да и большенству наших это не очень актуально, затея представляется утопичной из-за сложности и отсутствия ну очень заинтересованных в этом лиц.
Значит проще одной ногой колесо крутить, другой пружину прижимать, а руками рулить и бибикать? И так каждому кто заинтересован? Да, оно не так чтобы совсем горит, но если это запилить в мэйнстриме, то всем остальным останется только следовать стандартам. А лишняя длина имени карман не тянет.
У Линуса ЧСВ непропихивальное теперь, трудно будет
Дык, надо через Леннарта заходить. Чо как не русские-то.
Дык, надо через Леннарта заходить. Чо как не русские-то.
В смысле работать на красную шляпу?
В смысле работать на красную шляпу?
Просто подкинуть ему идею про vfsd.
Значит проще одной ногой колесо крутить, другой пружину прижимать, а руками рулить и бибикать? И так каждому кто заинтересован?
Задачу максимум (увеличение длины имени файла в самом ядре и включённых в него ФС) просто так не решить, это идеологический вопрос, который уже неоднократно поднимался, без результата. (Что-то не слышно при этом про большую активность разработчиков отечественных дистрибутивов, а уж они то должны быть заинтересованы.)
Задача минимум (дать пользователю возможность задать константу в произвольной ФС) требует написания кода. Зачем это делать, если можно просто взять Reiser4|Btrfs|ReiserFS? То есть задача усложняется, т.к. необходимы условия VLFN + невозможность использования Reiser*|Btrfs + способность писать код для ФС. Ну и где в живой природе это можно встретить? Так что патчей нет и продвигать в этом плане нечего.
Но это ведь будет Linux-specific решение?
А вот POSIX спасёт всех поголовно.
Интересное мнение из сообщения 2008 года:
It’s very difficult to solve all these problems in the kernel, libc,userspace, I know, but I think we should keep the option to fix themin the future. Maybe in the next POSIX standard, we should changeNAME_MAX to [255 * max_bytes_per_character] ?
Так что желающие могут попытаться зайти через Российскую секцию IEEE.
PS. Если кто может, исправьте link выше. Это ссылка на сообщение содержащее цитату.
А не проще начать хранить содержимое файлов ВНУТРИ файлов?
А не проще начать хранить содержимое файлов ВНУТРИ файлов?
Вот представь себе: приносят тебе уже ГОТОВЫЕ файлы с длиннющими именами в кириллице.
Ты реально будешь в такой ситуации переименовывать эти файлы?
А если ты эти файлы должен будешь отдать дальше по workflow?
Мне БД вполне заменяет при этом нормальная ФС + Emacs с Helm. Зачем огород городить?