Для русских букв в Linux ограничение на длину названия файла в два раза меньше, чем Windows: В Linux — 255 байт (и кодируем в UTF-8, в Windows — 260 символов (кодированных в UTF-16 (UCS2). Вот подобная заявка: https://bbs.archlinux.org/viewtopic.php?id=89174 Пределы заданы в ядре: include/linux/limits.h #define NAME_MAX 255 /* # chars in a file name */ #define PATH_MAX 4096 /* # chars in a path name including nul */ Не проблема пересобрать ядро, не проблема пропатчить нужные приложения. Проблема в файловых системах: их может быть поменять гораздо сложнее, сохранив совместимость. Возможно, что есть файловые системы, имеющие ограничение больше, чем в 255 байт. В итоге, для достижения интероперабельности требуется увеличить длину названия файла как минимум до 2*260 = 520 байт. Возможно, что у пользователей иероглифической письменности возникнут пожелания и в 780 символов. Подробнее на тему использования ограничения в программах: В glibc так же заданы пределы: PATH_MAX (defined in limits.h) FILENAME_MAX (defined in stdio.h) FILENAME_MAX is part of the ISO C standard, it works on UNIX and Windows. However, the GNU C library documentation contains the following warnings: "Unlike PATH_MAX, this macro is defined even if there is no actual limit imposed. In such a case, its value is typically a very large number. This is always the case on the GNU system. Usage Note: Don't use FILENAME_MAX as the size of an array in which to store a file name! You can't possibly make an array that big! Use dynamic allocation." http://en.wikipedia.org/wiki/Filename FILENAME_MAX 4096 /usr/include/bits/stdio_lim.h http://linux.derkeiler.com/Mailing-Lists/Kernel/2005-06/2426.html http://stackoverflow.com/questions/833291/is-there-an-equivalent-to-winapis-max-path-under-linux-unix?rq=1 http://www.gnu.org/software/libc/manual/html_mono/libc.html#Limits-for-Files _PC_NAME_MAX _PC_PATH_MAX http://www.gnu.org/software/libc/manual/html_mono/libc.html#Pathconf _POSIX_PATH_MAX /usr/include/bits/posix1_lim.h /usr/include/cc++/file.h #define PATH_MAX 256 http://linux.about.com/library/cmd/blcmdl3_pathconf.htm
Немного исследовал проблему. Действительно большинство линуксовых файловых систем (ext*, xfs, btrfs) имеют ограничение в 255 символов на длину имени файла. Исключением в данном случае является только reiserfs. Можно попробовать конечно пропатчить ядро и использовать эту фс, но возможность использования только для одной фс выглядит малопривелкательной.
Ссылка на обсуждение в linux-cifs-client@: https://lists.samba.org/archive/linux-cifs-client/2006-March/001230.html NFS - лимит 255 символов. CIFS - 260 символов UTF-16.
Описание структуры ext4 на диске. https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout Надо изучить и понять ограничения, нужно ли создавать файловую систему с расширенным ограничением, или всё упирается в то, что длина имени файла хранится в одном байте...
Если я правильно понял, то изначально в файловой системе EXT использовалось ограничение на длину имени файла в 255 символов, а размер самого поля имени был 2 байта: 4 /* 5 * The ext filesystem constants/structures 6 */ 7 8 #define EXT_NAME_LEN 255 55 struct ext_dir_entry { 56 unsigned long inode; 57 unsigned short rec_len; 58 unsigned short name_len; 59 char name[EXT_NAME_LEN]; 60 }; В новых же системах, начиная с ext2 длину файла намеренно уменьшили до 1 байта, а младшие байт отвели под флаги определения типа файла. Linux /fs/ext4/ext4.h: 1576 #define EXT4_NAME_LEN 255 1577 1578 struct ext4_dir_entry { 1579 __le32 inode; /* Inode number */ 1580 __le16 rec_len; /* Directory entry length */ 1581 __le16 name_len; /* Name length */ 1582 char name[EXT4_NAME_LEN]; /* File name */ 1583 }; 1584 1585 /* 1586 * The new version of the directory entry. Since EXT4 structures are 1587 * stored in intel byte order, and the name_len field could never be 1588 * bigger than 255 chars, it's safe to reclaim the extra byte for the 1589 * file_type field. 1590 */ 1591 struct ext4_dir_entry_2 { 1592 __le32 inode; /* Inode number */ 1593 __le16 rec_len; /* Directory entry length */ 1594 __u8 name_len; /* Name length */ 1595 __u8 file_type; 1596 char name[EXT4_NAME_LEN]; /* File name */ 1597 }; Но первая структура, как видно, осталась, может можно пользоваться как-то ею, потому что других ограничений кроме однобайтности поля имени файла в самой файловой системе не видно.
(В ответ на comment #4) > Если я правильно понял, то изначально в файловой системе EXT использовалось > ограничение на длину имени файла в 255 символов, а размер самого поля имени > был 2 байта: ... > В новых же системах, начиная с ext2 длину файла намеренно уменьшили до 1 > байта, а младшие байт отвели под флаги определения типа файла. О, это очень интересно. > 1576 #define EXT4_NAME_LEN 255 > 1577 > 1578 struct ext4_dir_entry { > 1579 __le32 inode; /* Inode number */ > 1580 __le16 rec_len; /* Directory entry length */ > 1581 __le16 name_len; /* Name length */ > 1582 char name[EXT4_NAME_LEN]; /* File name */ ... > 1586 * The new version of the directory entry. Since EXT4 structures are > 1587 * stored in intel byte order, and the name_len field could never be > 1588 * bigger than 255 chars, it's safe to reclaim the extra byte for the > 1589 * file_type field. Мне кажется, это было очень плохой идеей. Неплохо бы поискать, как они до этого додумались. Почему просто не расширили структуру. > 1591 struct ext4_dir_entry_2 { > 1592 __le32 inode; /* Inode number */ > 1593 __le16 rec_len; /* Directory entry length */ > 1594 __u8 name_len; /* Name length */ > 1595 __u8 file_type; > 1596 char name[EXT4_NAME_LEN]; /* File name */ > 1597 }; > > Но первая структура, как видно, осталась, может можно пользоваться как-то > ею, потому что других ограничений кроме однобайтности поля имени файла в > самой файловой системе не видно. Нет, думаю у нас должна появиться ext4_dir_entry_3. Но это структура хранения где — на диске или в памяти? Может быть будет проще подойти со стороны утилиты mkfs.ext4, которая создаёт файловую систему. Если она это делает самостоятельно, без ядра, то можно начать модификацию с неё — видимо, добавив флаг, включающий режим длинных имён.
(В ответ на comment #1) > Немного исследовал проблему. Действительно большинство линуксовых файловых > систем (ext*, xfs, btrfs) имеют ограничение в 255 символов на длину имени > файла. Исключением в данном случае является только reiserfs. Можно > попробовать конечно пропатчить ядро и использовать эту фс, но возможность > использования только для одной фс выглядит малопривелкательной. Про ReiserFS на википедии пометка Максимальная длина имени файла 4032 байт, limited to 255 by Linux VFS Но при этом в описании структуры имени файла в VFS отводится 2 байта http://www.win.tue.nl/~aeb/linux/lk/lk-8.html : struct qstr { const unsigned char *name; unsigned int len; unsigned int hash; };
(В ответ на comment #6) ... > Про ReiserFS на википедии пометка > > Максимальная длина имени файла > > 4032 байт, limited to 255 by Linux VFS > > Но при этом в описании структуры имени файла в VFS отводится 2 байта Возможно, это ссылка 10-летней давности. reiserfs не очень интересна, потому что не развивается. > http://www.win.tue.nl/~aeb/linux/lk/lk-8.html : > > struct qstr { > const unsigned char *name; > unsigned int len; > unsigned int hash; > }; В C-библиотеке есть dirent http://www.gnu.org/software/libc/manual/html_node/Directory-Entries.html И кошмар потом будет с ней. Правда в документации написано про unsigned char d_namlen а на деле структура такие поля имеет: struct dirent { __ino_t d_ino; __off_t d_off; unsigned short int d_reclen; unsigned char d_type; char d_name[256];<-><------>/* We must not include limits.h! */ }; Ну и глупые , что не должны ключать limits.h
Формулировка проблемы на русском и обходной путь для решения (к сожалению, он не может работать, но можно сделать, чтобы он работал) http://bb.comp-house.ru/comp-house.repo/wiki/linux-long-filenames Описание проблемы с MacFUSE, признание, что на Маке такая же проблема, и расчёт, что для представления 255 корейских букв нужно 2295 байт: https://groups.google.com/forum/#!topic/macfuse/g9uB-PVoJ2o Видимо, корейцам, японцам и китайцам проблема ещё более актуальна, чем русским. Есть интересная идея, которая позволит не переделывать файловые системы, предлагая тормозной вариант: реализовать укорачивание файлов через fuse. Ничего готового я не нашёл (если не считать перекодирования в 8-битную кодировку, как описано выше), но есть много похожего: http://sourceforge.net/apps/mediawiki/fuse/index.php?title=DatabaseFileSystems Нужно придумать, как поставленная проблема будет называться на английском. Проблема в том, что Long Filenames принято называть имена, которая придумала MS для расширения DOS-имён 8.3 в длинные.
(В ответ на comment #8) > Формулировка проблемы на русском и обходной путь для решения (к сожалению, > он не может работать, но можно сделать, чтобы он работал) > http://bb.comp-house.ru/comp-house.repo/wiki/linux-long-filenames > Кажется, что подход, основанный на создании ФС в userspace - наиболее простое решение и наименее проблемное. > > Есть интересная идея, которая позволит не переделывать файловые системы, > предлагая тормозной вариант: > реализовать укорачивание файлов через fuse. > Ничего готового я не нашёл (если не считать перекодирования в 8-битную > кодировку, как описано выше), но есть много похожего: > http://sourceforge.net/apps/mediawiki/fuse/index. > php?title=DatabaseFileSystems Не совсем понятно каким именно образом будет укорачиваться это имя.
Предлжение по названию проблемы: Short filename's length in Linux. Или по названию баги: Increasing filename length in Linux
Имена будут отображаться, как есть, а при обращении к ним, модуль ядра FUSE будет перехватывать эти обращения и приводить имена к формату, понятному vfs(<=255 byte)?
(В ответ на comment #10) > Предлжение по названию проблемы: Я подумал, что надо попробовать предложить термин VLFN - Very Long FileNames Это будет как бы продолжением темы LFN (Long FileNames), с которой Microsoft когда-то сделала прорыв.
(В ответ на comment #7) > (В ответ на comment #6) > В C-библиотеке есть dirent > http://www.gnu.org/software/libc/manual/html_node/Directory-Entries.html > > И кошмар потом будет с ней. Правда в документации написано про unsigned char > d_namlen > а на деле структура такие поля имеет: > > struct dirent > { > __ino_t d_ino; > __off_t d_off; > unsigned short int d_reclen; > unsigned char d_type; > char d_name[256];<-><------>/* We must not include limits.h! */ > }; > Ну и глупые , что не должны ключать limits.h оказывается , что там в структуре dirent нет длины имени файла, d_reclen - длина самой записи
Написана небольшая программа, которая пытается создать файл, с указанным в ней именем, а затем проверяет был ли файл создан и, если да, выводит его имя и длину имени. Затем выводит некоторые статические ограничения на длину файла из limits.h. В планах разобраться с динамическими ограничениями, управляемыми функциями sysconf, pathconf, fpathconf. Посмотреть , что будет, если длина файла будет занимать больше 255 байт.
(В ответ на comment #15) > Написана небольшая программа, которая пытается создать файл, с указанным в > ней именем, а затем проверяет был ли файл создан и, если да, выводит его имя > и длину имени. Ну выводить имя стоит в любом случае. И быть готовым к тому, что в следующей версии нужно будет опытным путём (уменьшая длину имени, пока не создастся файл) определить реальное ограничение. > В планах разобраться с динамическими ограничениями, управляемыми функциями * получаемыми через функции…
В программу добавлен вывод функции fpathconf, которая выводит ограничения( в нашем случае NAME_MAX и PATH_MAX) для конкретного файла, по его дескриптору
В программу добавлен вывод функции pathconf, которая выводит ограничения( в нашем случае NAME_MAX и PATH_MAX) для конкретного файла, по его имени. Функция sysconf подобной информации не предоставляет и на данный момент отсутствует. Добавлена функция генерации длинных имен файлов. При создании файлов длинной >255 символов происходит ошибка.
(В ответ на comment #18) > В программу добавлен вывод функции pathconf, которая выводит ограничения( в > нашем случае NAME_MAX и PATH_MAX) для конкретного файла, по его имени. Этот текст уже был :) Потренируйся с Git http://wiki.etersoft.ru/GitTask и публикуй свой репозиторий
Добавлена функция поиска наибольшей доступной длины имени, с которым можно создать файл.
Кажется правильным попытаться сначала создать файл с длинным именем - посмотреть, какие ограничения накладывает сама функция open() из glibc и убрать их.
Там в различных местах (ядра и glibc) может быть вбито число 255, без использования каких-либо констант. Это стоит признать неправильным, и заменить числа на соответствующие константы, возможно, для начала, с нестандартным названием, раз уж они не могут по каким-то соображениям (которые хорошо бы выяснить) использовать стандартные константы.
Ограничения на длину имени создаваемого файла в линукс задается числом : struct dirent { #ifndef __USE_FILE_OFFSET64 __ino_t d_ino; __off_t d_off; #else __ino64_t d_ino; __off64_t d_off; #endif unsigned short int d_reclen; unsigned char d_type; char d_name[256]; /* We must not include limits.h! */ }; Видимо, связано это с тем, что в файле glibc/posix/glob.c определяется переменная NAME_MAX следующим образом: /* NAME_MAX is usually defined in <dirent.h> or <limits.h>. */ #include <limits.h> #ifndef NAME_MAX # define NAME_MAX (sizeof (((struct dirent *) 0)->d_name)) #endif Почему не используется какая-либо константа в самом файле dirent.h, почему нет ее определения в файле limits.h библиотеки glibc - непонятно. Найти, где конкретно реализован вызов open, чтобы увидеть там проверку соответствия длины файл, пока не получилось
В планах - исправить в glibc значения констант, добавить функциональность, при которой при создании файлов будут выводиться диагностические сообщения. Далее тоже самое сделать с vfs. Все это попробовать запустить на системе с reiserfs или подобной, где нет ограничения на длину имени файла 255 байт.
нашел код функции open(), сложен для понимания: __fortify_function int open (const char *__path, int __oflag, ...) { if (__va_arg_pack_len () > 1) __open_too_many_args (); if (__builtin_constant_p (__oflag)) { if ((__oflag & O_CREAT) != 0 && __va_arg_pack_len () < 1) { __open_missing_mode (); return __open_2 (__path, __oflag); } return __open_alias (__path, __oflag, __va_arg_pack ()); } if (__va_arg_pack_len () < 1) return __open_2 (__path, __oflag); return __open_alias (__path, __oflag, __va_arg_pack ()); При этом: extern int __REDIRECT (__open_alias, (const char *__path, int __oflag, ...), open) __nonnull ((1)); а, # define __REDIRECT(name, proto, alias) name proto __asm__ (__ASMNAME (#alias)) и это говорит о том, что вызывается ассемблерная вставка open. возможно, я не прав.
Было выяснено утилитой strace, что ошибку возвращает системный вызов ядра open(): open("a1234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456", O_WRONLY|O_CREAT|O_TRUNC, 0401) = -1 ENAMETOOLONG (File name too long) Чтобы выявить функцию, вызывающую данную ошибку при создании файла, рядом с каждой отсылкой идентификатора ошибки был поставлен вывод сообщения ядра по типу: --- a/fs/dcache.c +++ b/fs/dcache.c @@ -2499,8 +2499,10 @@ EXPORT_SYMBOL_GPL(d_materialise_unique); static int prepend(char **buffer, int *buflen, const char *str, int namelen) { *buflen -= namelen; - if (*buflen < 0) + if (*buflen < 0) { + printk("dcache.c error prepend()\n"); return -ENAMETOOLONG; + } *buffer -= namelen; memcpy(*buffer, str, namelen); return 0; вопрос: нужен ли в printk() параметр по типу KERN_INFO. Так же необходимо сделать так, чтобы в каждом измененном файле был подключен linux/kernel.h Планируется протестировать ядро на виртуальной машине. На данный момент, после изучения кода ядра, складывается ощущение, что практически все зависит от заданного ограничения NAME_MAX или аналогичных ограничений конкретных файловых систем.
(В ответ на comment #26) ... > На данный момент, после изучения кода ядра, складывается ощущение, что > практически все зависит от заданного ограничения NAME_MAX или аналогичных > ограничений конкретных файловых систем. Ну вообще информация о NAME_MAX дана в исходных данных задачи, это то, с чего нужно было начать — изменить константу и скомпилировать ядро. Дальше уже смотреть, что где вылезет. Собственно, с NTFS или reiserfs ничего вылезти и не должно.
Было поставлено ядро с выводом диагностических сообщений, которые показали, что выводится диагностическое сообщение соответствующее ext4, #dmesg: [ 721.248824] EXT_4_ERR Программа, создающая файлы, была изменена, теперь она так же создает длинный файл(>255 байт) русских символов. При запуске программы из разделов ntfs и raiserfs было выявлено, что в файловой системе ntfs файл с длинным русским именем создается, в противоположность этому в reiserfs - нет. На данный момент можно предположить, что основным ограничением является ограничение на длину со стороны файловой системы. Роль в ограничения со стороны vfs и glibc не ясна. В планах просмотреть, как работают функции, оперирующие именами. Из все этого следует, что необходимо создать тест, который будет проверять функции, оперирующие с именами, исправить нужные функции в glibc, выбрать файловую систему, в которой будет проще всего сделать изменения и провести их.
В связи с задачей совмещения нескольких репозиториев в один, написан скрипт для перемещения всех файлов в подпапку с перезаписью путей к файлам. основная идея взята отсюда: http://ahitrin.github.io/work/2012/07/16/%D0%A1%D0%BB%D0%B8%D1%8F%D0%BD%D0%B8%D0%B5-%D1%80%D0%B5%D0%BF%D0%BE%D0%B7%D0%B8%D1%82%D0%BE%D1%80%D0%B8%D0%B5%D0%B2-%D0%B2-git/ скрипт: current_dir=${PWD##*/} temp_dir=tmpdir git filter-branch --tree-filter 'mkdir ../tmpdir; mv ./* ../tmpdir; mv ../tmpdir ./$current_dir/; mv ./$current_dir/tmpdir ./$current_dir/$current_dir' master перед запуском необходимо перейти в директорию репозитория. Далее планируется действовать по аналогии со статьей по ссылке.
Тестовая программа теперь в репозитории: git.eter:/people/reprofy/public/glibc_tests.git
Были изучены системы jfs и btrfs, в которых были найдены соответствующие ограничения, краткое описание практического сравнения уже здесь есть: http://wiki.etersoft.ru/Comparison_of_file_systems В этих двух системах были изменены значения ограничений, после чего была произведена попытка их запуска. В планах рассмотреть варианты других систем, возможно, менее популярных, оценить сложность их исправления под наши нужды, глубже разобраться в плюсах и минусах btrfs и jfs. Оценить системы EXTx. Добавлен вывод ошибки, если не удается создать файл с длинным название в testfilenames.
Изменен предел для xfs, в этой версии создать файл удалось, но после возникла ошибка: [root@host-35 xfs]# ls ls: невозможно открыть каталог .: Ошибка ввода/вывода
в планах - увеличить ограничение на ext4, провести более обширный тест btrfs
В btrfs файл был создан и была выведена соответствующая информация. Однако, обнаружить файл визуально не удалось. При попытке создать директорию с длинным именем, визуально, создалось множество директорий, имена которых были кусками имени предполагаемой к созданию директории. Но так как btrfs - единственная фс, каталоги с которой все-таки открываются после создания файла с длинным именем, то кажется целесообразным рассмотреть ее в качестве кандидата на решение данной задачи: https://bugs.etersoft.ru/show_bug.cgi?id=9672
создана страница wiki http://wiki.etersoft.ru/Linux/VLFN
Так как тесты btrfs не выявляют ошибок, в планах рассмотреть, как необходимо изменить glibc для корректной работы с измененной ФС.
Откладываем задачи, к которым не обращались более 100 дней.
Обсуждение проблемы на LOR образца 2009 года: http://www.linux.org.ru/forum/general/3451283 Список лимитов на файлы: http://serverfault.com/questions/9546/filename-length-limits-on-linux
