Linux имя файла длина

Правила именования файловых объектов в Astra Linux

Термином «имена файловых объектов» обозначаются имена файлов и каталогов, далее для краткости используется термин «имена файлов», при этом правила именования для файлов и каталогов одинаковы. Далее п одразумевается, что используется стандартная для Astra Linux файловая система ext4.

Данная статья применима к:

• Astra Linux Special Edition РУСБ.10015-01 и РУСБ.10015-10 (очередное обновление 1.7)
• Astra Linux Special Edition РУСБ.10015-37 (очередное обновление 7.7)
• Astra Linux Special Edition РУСБ.10015-01 (очередное обновление 1.6)
• Astra Linux Special Edition РУСБ.10015-16 исп. 1 и 2
• Astra Linux Special Edition РУСБ.10015-01 (очередное обновление 1.5)
• Astra Linux Special Edition РУСБ.10265-01 (очередное обновление 8.1)

Регистр

Имена файлов в Astra Linux чувствительны к регистру. То есть, например: AstraLinux, Astralinux, и astralinux — это три разных имени файлов.

Кодировка кириллицы

Для имен файлов, содержащих символы кириллицы, используется кодировка UTF-8. Следует помнить, что при использовании этой кодировки одному символу кириллицы соответствует 2 байта, другим символам (например, диакритическим) может соответствовать до четырех байт.

Длина имени файла и пути к файлу

Имена файлов в Linux могут быть длиной до 255 байт.

Полная длина пути к файлу (включая имя файла) не должна превышать 4096 байт.

При использовании кириллицы и диакритических символов следует помнить, что одному такому символу соответствует до четырех байт. В частности, увеличение длинны имен при их перекодировке может привести к затруднениям при копировании или разархивировании файлов из систем, использующих кодировку CP-1251 или KOI-8, в системы с кодировкой UTF-8.

При архивировании могут действовать ограничения, зависящие от используемой системы архивирования (и, в некоторых случаях, от типов архивируемых файлов). Более подробную информацию см. в документации на используемые архиваторы. Так, например:

• архиватор tar:
  • версия gnu — длина не ограничена (эта версия входит в дистрибутивы Astra Linux);
  • версия v7 — максимальная длина полного имени файла 99 байт;
  • версия ustar — максимальная длина полного имени файла 256 байт, максимальная длина имени символьной ссылки — 100 байт;

  При использовании оптических дисков (файловая система ISO 9660) действуют следующие ограничения:

  • длина пути не более 1024 байта;
  • длина имени файла:
    • оригинальная версия ISO9660 — 32 байта;
    • версия файловой системы Joliet — 128 байт;
    • версия файловой системы Rockridge — 255 байт.

    Специальные символы (метасимволы)

    Некоторые символы или последовательности символов зарезервированы для специального использования, и их не рекомендуется применять в именах файлов:

    При сравнении имен файлов — любой символ из указанного в квадратных скобках диапазона, например:

    • [a-z] любая латинская буква в нижнем регистре;
    • [A-Z] любая латинская буква в верхнем регистре;
    • 9 любая десятичная цифра;
    • [0-9A-Fa-f] любая шестнадцатеричная цифра (в любом регистре);
    • [a-zA-Z0-9] любая латинская буква в любом регистре или десятичная цифра.

    Допустимые символы в именах файлов

    Минимальный безопасный набор символов для использования в именах файлов:

    • буквы (как латиницы, так и кириллицы, в любом регистре);
    • цифры;
    • символ «.» (точка);
    • символ «_» (подчеркивание)
    • символ «-» (тире).

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

    Решение проблем с метасимволами в именах файлов при работе в командной строке

    В Astra Linux можно создать имена файлов содержащие любой символ, включая непечатные (невидимые) символы и метасимволы. Далее приведены некоторые приемы для работы с такими именами файлов.

    Автозавершение

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

    Замена невидимых символов

    Для указания файлов с невидимыми символами можно использовать символ «*», обозначающий любой символ, например, переименовать файл с именем badname, содержащим невидимый символ:

    Экранирование метасимволов

    Для управления файлами с именами, содержащими метасимволы, можно использовать:

    • символы «одинарная кавычка», внутри которых метасимволы потеряют свои специальные значения;
    • символ «обратная косая черта», отменяющий специальное значение следующего за ним символа;

    позволит переименовать файл с «неудобным» именем *Astra*Linux* в файл с другим «неудобным» именем, содержащим пробел.

    Для имен файлов, начинающихся с символа «минус» можно использовать указание их имени относительно текущего каталога:

    Символы «./» в начале имени файла обозначают «текущий каталог», и позволяют скрыть лидирующее тире, чтобы команда rm не воспринимала имя файла как опцию.

    Имена файлов, начинающиеся с символа «-«

    Большинство команд используют символ «-» (минус) для обозначения опций (параметров) выполнения. Для того, чтобы можно было передавать командам аргументы (например, имена файлов), начинающиеся со знака «-» (минус) и не являющиеся опциями, используется специальная опция «—» (два минуса). Эта опция указывает, что все последующие аргументы команды не являются опциями независимо от наличия лидирующего символа минус. Например, чтобы удалить файл, имеющий имя «-filename», команду rm можно использовать в виде:

    Источник

    Как увеличить лимит 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. Зачем огород городить?

    Источник

    Читайте также:  Просмотр скрытых папок linux