Linux max filename length

Ограничения длины имени файла на Linux?

Есть ли какие-либо ограничения на длину файла или пути в Linux?

См. Страницу Википедии о сравнении файловых систем , особенно в столбце Максимальная длина имени файла .

Вот некоторые ограничения длины имени файла в популярных файловых системах:

Я читал здесь, что ограничение длины пути в системных заголовках. Ограничение длины имени файла тоже там. В моей системе это файл:

и C-lang определяет:

Я имею в виду другие ответы, пожалуйста, проголосуйте за них.

Есть ли какие-либо ограничения на длину файла или пути в Linux?

Да, длина имени файла и пути ограничена:

Чтобы динамически получить эти свойства:

• Используйте функции pathconf и fpathconf как предложено Майклом Аароном Сафяном
• Создайте имя файла (или путь к файлу ) длиннее и длиннее, как объяснено dogbane

Используйте команду, getconf предложенную Тимом, которая также доступна в Linux:

И ради экономии времени (и привязки его к памяти):

ext2, ext3, ext4, zfs: без ограничений пути; Ограничение имени файла 255 байт.

Это длины имен файловых систем. У самого «linux» тоже есть. Например, из бит / stdio_lim.h:

Там нет никакого способа , чтобы определить максимальную длину путей на Linux переносимым способом. В моей системе:

Но я могу легко создавать пути намного длиннее, чем 4096 символов. Вместо этого смотрите PATH_MAX как нижнюю границу. Вы гарантированно сможете создавать пути так долго, но вы также можете создавать гораздо более длинные.

Вы всегда должны использовать pathconf или какую-либо функцию, подобную этой, чтобы получить значение времени выполнения для указанных элементов, поскольку на этой странице сказано, что:

Однако следует отметить, что многие из перечисленных пределов не являются инвариантными, и во время выполнения значение предела может отличаться от значений, указанных в этом заголовке, по следующим причинам:

Предел зависит от имени пути.

Предел различается между компиляцией и машинами времени выполнения.

По этим причинам приложение может использовать функции fpathconf (), pathconf () и sysconf () для определения фактического значения лимита во время выполнения.

Источник

Linux/VLFN

VLFN (Very Long FileName) — проблема, заключающаяся в том, что в большинстве Unix-систем (и в GNU/Linux в частности) применено ограничение в 255 байт на длину имени файла, что при использовании UTF-8 даёт для русских букв не более 127 символов.

В статье рассматриваются способы увеличения допустимой длины имени файлов в Linux и проблемы, с этим связанные.

Содержание

Имена файлов в Windows и Linux

В Windows для именования файлов принята кодировка UTF-16, то есть каждый символ в названии файла кодируется двумя байтами (16 бит). Максимальная длина имени файла — 255 символов (510 байт). В Linux же для именования файлов принята кодировка UTF-8, при этом максимальная длина файла составляет 255 байт (а не символов).

Причины проблемы

• Ядро внутри себя не имеет общей константы для ограничения длины имени файла. NAME_MAX в include/linux/limits.h нужна только для программ (попадает в glibc-headers).
• Файловые системы в ядре имеют ограничения по размеру (в ext3/4 вообще взяли и оставили 1 байт на хранение длины имени файла). В некоторых системах ограничение жёсткое (ext4), в некоторых — номинальное (btrfs).
• glibc нигде не касается данных, связанных с ограничением длины.

Постановка задачи

Так как в UTF-8 для кодирования русских букв используется два байта, то максимальная длина имени файла, состоящего из русских букв, фактически составляет 127 символов. В связи с этим появляется проблема — длинные имена файлов (от 128 до 255 русских символов) не влезают в установленные для них ограничения в Linux.

• NTFS — 256 символов UTF-16
• NFS — лимит 255 символов.
• CIFS — 260 символов UTF-16.

Решение

Необходимо увеличить возможную длину файлов в Linux.

Выбранная длина нового максимального предела имени файла — 1023 байта.

• нет привязки к Windows, поэтому нет необходимости задавать размер ровно 511 байт;
• имя файла задается с запасом, что позволит адаптировать ОС и ФС к иероглифической, к примеру письменности, где знаки могут занимать в районе 4 байт.

NAME_MAX free

Радикальным правильным решением для userspace является отказ от использования констант, задающих размер буфера под имя файла.

Файловые системы должны быть устроены таким образом, чтобы длина имени файла была переменной и не имела ограничений (кроме временных соображений совместимости).

Уже сделано

Был проведен тест файловой системы NTFS. Оказалось, что на данной можно создавать файлы с длинным русским именем, из чего следовало, что ограничение задается самой ФС, а не ядром или библиотекой glibc: https://bugs.etersoft.ru/show_bug.cgi?id=9266

Было решено выбрать файловую систему, которую легче всего было бы адаптировать для решения данной проблемы. Затем было проведено сравнение самых распространенных и перспективных файловых систем: http://wiki.etersoft.ru/Comparison_of_file_systems

Стоит рассмотреть такие системы как btrfs, xfs, ext4.

В итоге, благодаря гибкости и динамичности развития, была выбрана файловая система BTRFS.

BTRFS

B TRee File System — файловая система, основанная на структуре Б-деревьев и работающая по принципу «копирование при записи».

Изменения

Изначально изменен предел BTRFS_NAME_LEN, заданный в файле /fs/btrfs/ctree.h. Аналогичный предел был изменен в пакете BTRFS-progs.
Изменения:

Тестирование

Проведено тестирование основной функциональности новой файловой системы. Для граничных значение — 1024 и 1023 байта:

• При измененном ядре и измененной программе форматирования:

• При оригинальной версии программы для форматирования:

• При оригинальном ядре и измененной программе форматирования:

Применение

Для того, чтобы использовать файловую систему BTRFS с увеличенным пределом имени файла, необходимо:

1. Установить исправленную версию ядра ( git.eter:/people/reprofy/packages/kernel_sis.git -> btrfs_new_bound );
2. Отформатировать дисковый раздел, используя исправленную версию btrfs-progs ( git.eter:/people/reprofy/public/btrfs_progs.git -> filename_bound );
3. Для обеспечения полной функциональности необходимо изменить предел в файле limits.h:
   1. Установить исправленный пакет kernel-source-3.9 ( git.eter:/people/reprofy/public/kernel_source_3.9.git -> namelength_increased );
   2. Установить пакет glibc-kernheaders(из репозитория git.alt );

Glibc

В самой glibc вносить изменения не нужно, единственное, что требуется — изменить предел в файле limits.h.

Пакеты

Пакеты для ALT Linux в LINUX@Etersoft:

• glibc-kernheaders даёт возможность собирать программы с увеличенным ограничением
• btrfs-utils не будет ругаться на длинные имена при проверке ФС
• ядро с увеличенным ограничением для btrfs

Источник

Длинные имена файлов

Всем привет переношу файлопомойку с винды на линукс. Столкнулся с проблемой «очень длинных имён файлов». Похоже, счёт идет не на символы, а на байты (гугление это подтверждает). Внимание, вопрос: мне таки придётся использовать винду или есть какое-то решение этой проблемы? (усекновение имени — не решение в данной ситуации)

ext2/3/4,reiser,xfs,jfs — все поддерживают 255 символов в имени файла (или 127 в UTF8) — куда вам больше??

Поправочка: 127 русских букв, закодированных в UTF8.

UTF8 — однобайтовая кодировка, так что ASCII в UTF8 = ASCII 🙂

ФС те, которые поддерживаются CentOS 5.4 — то есть ext2/3, ext4 без mkfs.ext4, xfs на положении ext4.

127 букв — внезапно оказалось мало. Есть у пользователей такие имена файлов:

«Котов АН Моделирование дорожного движения на многополосной магистрали при помощи двумерного вероятностного клеточного автомата с тремя состояниями, 2008 (диссертация)»

Усекновение — не вариант. На винде такое имя файла обрабатвается корректно

$ echo «Котов АН Моделирование дорожного движения на многополосной магистрали при помощи двумерного вероятностного клеточного автомата с тремя состояниями, 2008 (диссертация)» | wc -c

$ touch «Котов АН Моделирование дорожного движения на многополосной магистрали при помощи двумерного вероятностного клеточного автомата с тремя состояниями, 2008 (диссертация)»

$ ls Котов*
Котов АН Моделирование дорожного движения на многополосной магистрали при помощи двумерного вероятностного клеточного автомата с тремя состояниями, 2008 (диссертация)

Вроде создался файл. ext3.

Если очень нужно, то можно поставить однобайтную локаль. Хотя да, не решение.

Источник

File name too long — как дальше жить.

За всю свою долгую практику я как-то не встречался с такой проблемой, но в последние дни повалило просто валом.

Дело в том, что от пользователей Windows 7 исходит огромное количество файлов с именами, состоящими из полных названий неких документов на русском языке, т.е. два байта на букву. Зачастую такие документы невозможно скопировать на Windows XP или Linux. Нет, имя не сокращается автоматически даже в Windows XP, а просто выдается ошибка — File name too long.

Как выяснилось, даже в новом хваленом btrfs тот же лимит длины имени файла — 255 байт.

Пока обходимся сокращением имени файла вручную, но это же не решение. Как дальше жить? На мой взгляд, нынешний линуксовый лимит неадекватно мал.

100000 лоровцев кукарекают, один чинит, nuff said.

пусть пользователи Windows 7 укорачивают свои файлы, что ещё делать )

Хорошая идея — сделать эту штуку по-нормальному, но уже на Rust’е.

Файловые системы должны быть надёжными.

Использовать XFS, в расширенных атрибутах (man attr) можно хранить любые пары: ключ:значение, где длина ключа до 255, а значения до 64к. Т.е. можно укорачивать имя файла по любому алгоритму, а оригинальное имя хранить в ext.attr.

да нормальный лимит. нефиг называть файлы как попало. мы одно время делали большие проекты, файлов было просто дохрена. и схемы, и документация, и разработки по механике. миллионы файлов. и само дерево их хранения было довольно глубоким и развесистым. так в технической документации все файлы именовались кодом проекта по ГОСТ и буквенно-цифровой аббревиатурой, в которой зашифровано назначение файла. а длинные художественные названия и пояснения были в специальных справочных файлах, в которых кодовые имена сопровождались той самой фигнёй, которую юзер тщится впихнуть в название, да ещё и на русском языке.
думаю, есть утильки, которые тупо урезают имя файла при копировании.

Источник

Transmission: Невозможно скачать файл — слишком длинное имя

Unable to save resume file: File name too long

Пытаюсь скачать вот эту книжку:

Имя файла действительно очень длинное.

У меня убунта 12.04. Файловая система ext4.

Понятно, что можно поискать другие источники, другие торрент-клиенты или даже другие ОС.

Но хотелось бы понять, почему так. Ведь «в именах файлов можно даже делать абзацы»!

UPD Есть кто-нибудь с Убунтой 12.04? Потому что, как выясняется, такие проблемы только у меня.

wikipedia:
ext4:
Max. filename length 255 bytes (characters)
reiserfs:
Max. filename length 4032 bytes, limited to 255 by Linux VFS

Т.е. ограничение не FS, а VFS, т.е. другие операционные системы может быть спасут демократию в Нигерии.

edit: нет, не спасут. Вообще странная фигня какая-то: в NTFS ограничение те же 255 байт и как этот файл на винде работае не понятно.
Раздачу не смотрел, буду дома гляну.

На ubuntu 12.10 Transmission качает.

в NTFS ограничение те же 255 байт

Не байт, а символов в UTF-16.

qbittorrent скачал на ext3 debian6

в NTFS ограничение те же 255 байт

Nope. 255 двубайтных символов UTF16.

Вполне может быть, что ограничение не имени файла, а общей длины пути до файла. Попробуй качать поближе к корню.
Хотя это совсем странно будет.

Debain Wheezy AMD64 ext4, 2 Tb

оно же даже меньше 255 символов, в чем проблема?

Я это знаю. Качал вообще в корень — тоже самое.

Трансмишн скачал успешно в раздел NTFS, но (!) опять написал ошибку о «длинном» имени и невозможности сохранить файл, хотя сохранил всё прекрасно.

Ktorrent — тоже самое.

а если просто создать такой файл, например через текстовый редактор?

Копирую файл из NTFS раздела в корень — ошибка, имя файла слишком длинное.
Просто создаю тектовый файл с таким именем, без расширения — такая же ошибка.

Но если сократить имя до

Т.е. убрать вот это: ов — 2010

Файл создается и копируется.

Все правильно — в UTF16 получается что длинная имени 318 байт.

Убираем немного байтов и всё работает.

Вопрос: у тех, у кого работает — другая кодировка файловой системы что ли?

я на hfs+ проверял

Максимальная длина имени файла 255 символов (255 UTF-16 encoding units, normalized to Apple-modified variant of Unicode Normalization Format D)

а про ext4 пишут:

Максимальная длина имени файла 256 байт

У тебя путь какой, куда тащишь? Имя файла нормальное. Тоже трансмишн, тоже ext4, всё качается нормально.

Я сталкивался с точно такой проблемой. И тоже при загрузке книг (да на рутрекере очень странная политика на счет именования файлов).

Дело тут не в убунте. Суть такова: на NTFS длина имени 255 символов, а в линуксе — 255 байт, т.е. для utf-8 будет 127 русских букв. Причем просто качать на NTFS в линуксе видимо не выход, т.к. ограничение действует на уровне VFS, т.е. в ядре. Как вариант можно качать на ФС примонтированную с koi8-r или другой однобайтовой кодировкой.

deluge справится. Она кажется переименовывает файл с длинным именем и качает.

Про кодировку тебе рассказали, ещё transmission делает копию торрент файла и создает .resume файл с информацией раздаче. Их имена зависят от содержимого торрент файла + 16 символов на хэш.
Можешь использовать FUSE для папки transmission и раздач, там ограничение немного повыше.
Переименование в transmission пока только в git ветке.
Тем кто думает что 255 байт хватит всем — позавчера хотел скачать серию , а там название + название серии уже 188 байт(на русском было бы 347 байт), скачал другой рип.

Ты выбрал «шифровать диск» при установке? Это уменьшает максимальную длину имени с 255 байт до примерно 140-146.

Debian, ext4, кодировка пути по умолчанию. Файл нормально скачался с помощью Tixati. И открывается тоже нормально.

Названия файлов на русском и ограничения на длину имени файла в Linux (VFS) http://rutracker.org/forum/viewtopic.php?t=2655530

Спасибо. Разгадали.

Ты выбрал «шифровать диск» при установке? Это уменьшает максимальную длину имени с 255 байт до примерно 140-146.

Решение.

Та же проблема была вот сейчас.

Решил тем, что сохранил книгу на флешку, сформатированную в NTFS.

Re: Решение.

reiserfs лучше, и нифига ты не решил. Transmission скачает, но не сможет сохранить состояние раздачи и будет выкидывать ошибку.

Re: Решение.

Если, конечно, у тебя не зашифрован только каталог загрузки и проблема ещё и в этом.

Не UTF-16, а UCS-2. В UTF-16 символ может быть в 4 байта.

Источник