В ядре Linux поломали и пофиксили юникод в именах файлов

Юникод сломать элементарно без регистронезависимости, без зависимости от кодировок и без всего остального. Просто взять и в одном месте приводить имена к NFC форме, в другой к NFD, в третьей оставить ввод пользователя без нормализации как есть.

Что за NFC NFD? Ядро ничего никуда не приводит. Имя файла это массив байт, заканчивающийся нулевым байтом. Всякие кодировки появляются уже в юзерспейсе в прогах.

Я лично давно их использую, в первую очередь для сортировки.

Я не про ядро, я вообще. А про NFC/NFD - буквы юникода с диакритикой и не только можно представить как одним так и двумя символами. Оба варианта правильны, оба варианта используются юзерспейсовым софтом. В бинарном виде они будут отличаться и наивный поиск со сравнением по байтам работать не будет.

Тема то про ядро.

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

Да, они будут отличаться и это действительно разные имена. Путать их друг с другом не надо, несмотря на то что в юникодной кодировке они выглядят внешне одинаково. Если допустим есть две байтовые последовательности A и B, которые в юникоде обозначают одно и то же, и ты хочешь открыть файл A, но его нет а есть файл B - то правильным ответом будет именно «нет такого файла».

Это примерно из той же серии что кирилицу/латиницу в буквах а,с,е менять - внешне одно и то же, но байтовое представление разное, а именно оно важно.

это действительно разные имена

Это одинаковые имена, несмотря на то что в бинарном виде они выглядят по-разному. В корректно поддерживающей уникод программе они будут считаться одинаковыми. И например нормально написанные программы считают хэши паролей так, чтобы они были одинаковыми независимо от NFC/NFD на входе.

Это вообще не повод для спора.

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

А на файловые операции это и не влияет. Подумаешь битики не совпадают при том что имена-то одинаковые. Влиять это начинает когда кто-то потом начинает делать поиск по этим битикам.

А по поводу casefold линус прав. Смена регистра в юникоде не коммутативна, ß -> SS -> ss как самый известный пример.

Ядро ничего никуда не приводит.

Видимо, этот код лишний: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/fs/unicode

Разупорись.

Ты не в ту сторону смотришь. Имя файла это именно биты и есть. Всякие юникоды это их опциональная интерпретация (а может быть и другая - кодировок много), и они в норме могут применяться только в тех рамках, которые не нарушают корректную работу битового представления.

Лишний, да. Это видимо как раз кусок багнутого casefold-а. Либо костыль-адаптер ко всяким чужеродным фс типа ntfs-а.

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

Непонятно, почему написали только про f2fs. А как же ext4?

casefold
              This ext4 feature provides file system level character
              encoding support for directories with the casefold (+F)
              flag enabled.  This feature is name-preserving on the
              disk, but it allows applications to lookup for a file in
              the file system using an encoding equivalent version of
              the file name.

Я так сможешь ?

https://i.imgur.com/0fCnXcD.png

:-D

Сортировка делается уже в интерфейсе в соответствии с выбранной в том же интерфейсе локалью. То есть если ты в двух окна откроешь файловый менеджер с разными локалями то и сортировать он будет по-разному. Но к файловой системе это отношения не особо имеет. Это визуальное оформление.

Как-нибудь типа

export LC_ALL=ru_RU.[название кодировки]

в sh-подобной оболочке.

Сортировка делается уже в интерфейсе

Обратите внимание, что в сабжевом багрепорте ругался просто ls.

cd Picture
ls -alh
ls: cannot access '❤️': No such file or directory
total 8

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

Это каким «пони» нужно быть по жизни?

А как вы будете расширения исходникам на Mojo задавать? :-D

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

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

Да я не отрицал что баг есть. Но он не в файловой системе вообще а именно по причине того что в неё засунули этот ужасный костыль, весь смысл существования которого - совместимость с виндузятным софтом где такая же логика по умолчанию.

Но он не в файловой системе вообще

Он в ядре. В той его части, где происходит обработка имён файлов. «case folding in filesystems» является частью этой подсистемы ядра. Просто её можно не задействовать, да. А можно и задействовать.

Ля, у меня другая хрень, после включения компа, минуты три висит, органиченное соединене, и интернета нет, потом проходит...