Сколько символов может содержать имя файла в Linux

Обновлено: 05.07.2024

Если у вас есть несколько лет опыта работы с экосистемой Linux и вы хотите поделиться этим опытом с сообществом, ознакомьтесь с нашими Правилами участия.

1. Обзор

В системах на основе Unix существует ограничение на длину имен файлов. Это ограничение отличается в разных файловых системах.

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

2. Ограничения длины имени файла и файловые системы Unix

Большинство файловых систем Unix имеют одинаковые ограничения длины имени файла:

Однако, поскольку представление символа в формате Unicode может занимать несколько байтов, максимальное количество символов, составляющих путь и имя файла, может различаться.

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

У нас также могут быть расширения в нашей файловой системе, которые изменяют максимальный предел длины. Хорошим примером этого является eCryptFS, которая использует часть нижнего имени файла для хранения метаданных и устанавливает ограничение имени файла на 143 символа.

3. В поисках предела

В Linux есть удобная команда getconf для запроса переменных конфигурации системы.

Мы можем запустить его, чтобы найти предел длины имени файла:

Здесь конфигурация NAME_MAX представляет ограничение длины имени файла.

Аналогичным образом мы можем найти предел длины пути, изменив последнюю часть нашей предыдущей команды:

4. Подтверждение ограничений

Давайте воспользуемся стандартной командой touch, чтобы попытаться создать файл с именем, содержащим 258 символов, т. е. на три символа больше, чем ограничение в 255 символов:

Вот что мы получили:

5. Заключение

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

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

8 ответов 8

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

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

@rahmanisback подходит для ограничений на имена файлов, в то время как ограничения на пути обычно определяются ОС, а не файловой системой (за исключением некоторых странных файловых систем, таких как iso или ntfs), и в Linux они составляют 4 КБ

Я в шоке от этих ограничений. Количество файлов в каталоге неограничено, 4 миллиарда файлов на том, размеры файлов исчисляются терабайтами, размеры томов исчисляются эксабайтами, но у нас есть дурацкое ограничение в 255 байтов для имен файлов?

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

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

Извините, но я здесь новенький и не могу даже комментировать, сохраните голосование. Предыдущий ответ (от sfp) следует повысить, так как он полностью отвечает на вопрос, а другие частично отключены. Еще раз извините, что нарушаю правила, но я не могу молчать, когда лучший ответ находится внизу.

@DavidBalažic: Хотя PATH_MAX в Linux — это всего лишь рекомендация, большинство базовых файловых систем не имеют ограничений. Это затрудняет обращение к путям, превышающим этот размер. Обычно я использую «куски» PATH_MAX в качестве размера.

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

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

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

константы, определенные в linux/limits.h, как указано в sfp.

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

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

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

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

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

Однако большинство программ ограничены абсолютными путями до PATH_MAX = 4096 . Это можно обойти, если ваша программа может использовать относительные пути и вы сначала измените свой рабочий каталог.

Это связано с тем, что различные API POSIX, такие как getcwd и realpath (которые вы можете повторно реализовать в коде пользовательского пространства, прочитав метаданные для .а затем меняем на .. и повторяем до тех пор, пока не попадете в корень файловой системы), полагайтесь на PATH_MAX . (Источник)

Да, однако очень много разного библиотечного кода может сломаться, если ваш код изменит текущий каталог по желанию. Хорошо сделанный код не ломается, но большая часть существующего кода сделана плохо.

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

Таким образом, поскольку файловые системы extX имеют более низкий предел имени файла, чем тот, который определен в ядре, вы никогда не достигнете этого предела, если только он не включает пути, верно?

Мне так кажется. Также существует PATH_MAX для пути, который равен 4096, поэтому он будет срабатывать до «неограниченного» размера пути на расширениях. Я не уверен, как ОС разрешает свои внутренние ограничения и ограничения FS, никогда не заходил так глубоко. хотя вопрос интересный.

4096 символов — чертовски крутой путь. Я уверен, что это можно было бы поднять с помощью перекомпиляции, но, честно говоря, /зачем вам нужны такие длинные пути?/

Я не уверен, понадобится вам это или нет. Я рассматриваю это скорее как защиту от вредоносных или небрежных программ (я легко мог увидеть скрипт, который ведет себя плохо и начинает рекурсивно создавать один и тот же каталог. На самом деле, я сделал этот скрипт, но он перенаправлял веб-сайт, а не создавал каталоги). . ).

Невозможно определить максимальную длину путей в Linux переносимым способом. В моей системе:

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

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

Кроме того, например. модуль Python os.pathconf() будет иметь некоторые ответы; если порт Python хорош, они должны быть разумными.

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

Это правильный ответ, за исключением того, что это связано с комментарием @BjörnLindqvist. PATH_MAX — это всего лишь рекомендация, и 99 % файлов, вероятно, будут находиться в пределах этого ограничения.

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

Ограничение зависит от пути.
Ограничение различается для компьютеров компиляции и выполнения.

Он указывается в системном заголовочном файле limits.h.

Вот один из этих файлов:

Вот где находятся копии этого файла и значения, которые они определяют:

Очень активный вопрос. Заработайте 10 репутации (не считая бонуса ассоциации), чтобы ответить на этот вопрос. Требование к репутации помогает защитить этот вопрос от спама и отсутствия ответа.

Не тот ответ, который вы ищете? Просмотрите другие вопросы с меткой ограничения Linux или задайте свой вопрос.

Связано

Связанные

Горячие вопросы о сети

Чтобы подписаться на этот RSS-канал, скопируйте и вставьте этот URL-адрес в программу для чтения RSS.

Я новый пользователь eCryptfs, и у меня есть очень простой вопрос, который я нигде не смог найти. Я заинтересован в использовании eCryptfs через Synology NAS, использующий Linux.

При попытке зашифровать мою папку (EXT4) с помощью приложения для шифрования Synology (eCryptfs) я сталкиваюсь с ошибками, указывающими, что длина моего имени файла не может превышать 45 символов (поэтому шифрование не выполняется).

Если ограничение действительно составляет 45 символов, eCryptfs может не подойти для большинства пользователей.

Каков максимально допустимый размер имени файла при шифровании файлов и папок с помощью eCryptfs? В Linux 255 символов?

Imho, то, как ecryptfs шифрует имена файлов, просто смешно. Сначала он отдает более 20 байтов, добавляя фиксированную строку «ECRYPTFS_FNEK_ENCRYPTED». к каждому имени файла. Затем он добавляет слишком много случайных байтов, чтобы идентичные имена выглядели по-разному. EncFS делает это намного эффективнее.

4 ответа 4

Linux имеет максимальную длину имени файла 255 символов для большинства файловых систем (включая EXT4) и максимальную длину пути 4096 символов.

eCryptfs — это многоуровневая файловая система.Он размещается поверх другой файловой системы, такой как EXT4, которая фактически используется для записи данных на диск. eCryptfs всегда шифрует содержимое файлов, но при необходимости может шифровать (скрывать) имена файлов.

Если имена файлов не зашифрованы, вы можете безопасно записывать имена файлов длиной до 255 символов и шифровать их содержимое, так как имена файлов, записанные в более низкую файловую систему, будут просто совпадать. Хотя злоумышленник не сможет прочитать содержимое index.html или Budget.xls , он будет знать, какие существуют имена файлов. Это может (или не может) привести к утечке конфиденциальной информации в зависимости от вашего варианта использования.

Если имена файлов зашифрованы, все становится немного сложнее. eCryptfs добавляет немного данных перед зашифрованным именем файла, чтобы можно было окончательно идентифицировать зашифрованные имена файлов. Кроме того, само шифрование включает «дополнение» имени файла.

Например, у меня есть зашифрованный файл ~/.bashrc . Это имя файла зашифровано с помощью моего ключа для:

Очевидно, что 7-значное имя файла теперь требует для шифрования более 7 символов. Опытным путем мы обнаружили, что символьные имена файлов длиннее 143 символов начинают требовать > 255 символов для шифрования. Поэтому мы (как вышестоящие разработчики eCryptfs) обычно рекомендуем ограничивать имена файлов примерно 140 символами.

Итак, Synology NAS – это коммерческий продукт, в который встроены и используются eCryptfs и Linux для шифрования и защиты данных на устройстве. Мы (первоначальные разработчики eCryptfs) не имеем ничего общего с Synology или их продуктами, хотя в целом рады видеть, что eCryptfs используется в дикой природе. Мне кажется, что их рекомендация о 45 символах — это либо типографская ошибка (по сравнению с нашей рекомендацией о 140 символах), либо просто гораздо более консервативная оценка.

Вот как настраиваются записи каталогов в системном программировании C для Linux:

Как видите, имя файла представляет собой массив из 256 символов. Почему Linux ограничивает себя этим размером имени файла?

В качестве примечания: любые ссылки на действительно хорошие ресурсы или статьи по системному программированию Unix/Linux на C будут очень признательны.

В мире Unix это восходит к представлению BSD4.2 «Файловой системы Unix» (первоначально называвшейся «Fast File System») в начале 80-х годов. До этого имена файлов Unix были ограничены 14 символами.

Я не думаю, что есть какая-то другая причина, кроме того, что 256 "казался достаточно хорошим" в то время, и с тех пор ни у кого не было достаточно сильного желания изменить его. Однако первоначальный проект BSD был очень академическим (это был проект аспиранта), так что, вероятно, есть исследовательская работа, связанная с оригинальной FFS, если вы хотите попытаться найти ее.

(На самом деле это 255, потому что строка должна заканчиваться нулем.)

(На самом деле это 255, потому что строка должна заканчиваться нулем.)

Поскольку это фиксированный размер, не могли бы вы просто прочитать до 256 символов, и если он не завершается нулем, предположим, что длина строки составляет 256 символов?

Я предполагаю, что это внесет изрядную сложность для еще 1 символа.

Почему Linux ограничивает себя этим размером имени файла?

Каким он должен быть? Posix требует, чтобы он был ограничен NAME_MAX. Это может быть что угодно, но в моем дистрибутиве Linux это 255. Вы можете увеличить это значение и перекомпилировать свои библиотеки и приложения, если хотите, но люди Posix решили поставить постоянную длину времени компиляции для вещей когда-то. Они, вероятно, сделали это, потому что это делает работу с некоторыми вещами более удобной. Я предполагаю, что где-то есть код, который статически выделяет материал длиной NAME_MAX + 1, поэтому увеличение NAME_MAX, скажем, до 1 МБ, вероятно, приведет к тому, что некоторые программы будут использовать много памяти. так что это не было сделано.

Что касается того, почему Linux использует 256 вместо NAME_MAX + 1 в заголовке, посмотрите на системные заголовки. В моей системе файл /usr/include/x86_64-linux-gnu/bits/dirent.h содержит следующее:

Я предполагаю, что используется 256, а не NAME_MAX + 1, потому что они не хотят, чтобы заголовок ядра зависел от этого другого заголовка; возможно, это создает цикл зависимостей, где limit.h зависит от dirent.h и наоборот, чтобы найти различные константы. Я не уверен, какой стандарт «владеет» NAME_MAX, но, возможно, это то, что предоставляет ядро, и libc отвечает за настройку на основе ядра. Кажется немного странным, что в заголовках ядра не определена константа (для которой libc определяет NAME_MAX в Linux), которая также используется здесь и везде, где может отображаться имя файла, но я ожидайте, что у разработчиков ядра была причина для этого.

EDIT: обратите внимание, что Windows API имеет подобное ограничение:

Какова максимальная длина имени файла?

Windows обычно ограничивает имена файлов 260 символами. Но на самом деле имя файла должно быть короче, так как полный путь (например, C:\Program Files\filename.txt) включен в это количество символов. Вот почему вы можете иногда столкнуться с ошибкой при копировании файла с очень длинным именем файла в место, путь которого длиннее, чем его текущее местоположение.

Хм. Я думал, что у них максимальная длина пути составляет 1024 символа (или байта; не помню), но тогда я какое-то время не занимался программированием для Windows. хотя кажется, что 260 правильно.

В качестве примечания: любые ссылки на действительно хорошие ресурсы или статьи по системному программированию Unix/Linux на C будут очень признательны.

Похоже на довольно широкий спектр материалов, если вам нужны только статьи. Я имею в виду. возможно, вы захотите немного сузить область поиска. Я думаю, что книга Advanced Programming in the Unix Environment, вероятно, достойна прочтения, если вам просто нужна книга "C в Unix".

Читайте также: