Файловая система: Регистро-зависимая vs Регистро-независимая

Потому что регистрозависимые имена файлов – это просто естественный порядок вещей, в этом есть толика KISS.

Потому что

потому что что? преамбула будет? :о)

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

Дело не только в файловой системе как таковой, но и в предположениях, которые делают программы, которые поверх неё работают. То порты игр с Windows не запускаются, потому что пытаются открыть *.MAP, а есть только *.map, то в Git находят уязвимости, потому что кто-то не догадался, что .git/config и .GIT/CONFIG может оказаться одним и тем же файлом.

А чего непонятного? Символы английских A и a представлены разными последовательностями байт (разными байтами, если говорить о первой половине ASCII), во всех прочих кодировках так же, а код, как верно заметил анонимус, усложняется.

А смысл тут что-то обсуждать? Вроде очевидно всё.

мне-т все давно понятно. я завел эту тему, что-бы продолжить обсуждение тут а не в «офтоп-теме». т.е то, что вы «тут обьясняете», вы объясняете, по сути, не мне, а «сообществу».

андестенд?! :о)

по пунктам можно?

Всё правильно программы делают. Если пользователь дятел - это не их вина. MAP, Map, map, maP и прочие варианты - это разные названия, которые могли подразумевать нечто таким названием. И нечего за разработчика или пользователя додумывать.

А про то, что это виндопроблемы - вот пусть они голову из жопы и вытаскивают. Учатся заново писать. «Мама мыла раму»? Или «Мама мыла Раму».

Можно и по пунктам. Результат не изменится.

Файловая система очень сильно зависит от текстового представления. Путь, листинг файлов, поиск — это всё работа с текстом.

Но с текстом нельзя работать как попало. С помощью текста мы мыслим и общаемся, поэтому он должен быть удобным для восприятия и единообразным. Этим занимается типография.

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

Этого, в целом, должно быть достаточно. Компьютеры созданы для человека, а не человек для компьютера. Однако, столь общий аспект проникает во многие детали. Хочешь найти текстовые файлы? Будь добр, пиши \.[Tt][Xx][Tt]$. Или \.(txt|TXT)$, получая ясность в жертву корректности? Что делать с этим в код-ревью? Добавить ещё обработку пробелов в конце строки? В итоге мы ушли в куда-то далеко от простой идиомы \.txt$.

Сохранил данные в data.csv, затем в Data.csv, не заметив, что это разные файлы. Или программа читает файл settings.json, который пользователь назвал Settings.json.

Проблемы не заканчиваются на пользователях. В программировании нескрытые технические детали нужно обрабатывать на каждом слое абстракции. Сделал поле nil — будь добр, проверяй его на nil от SQL-запроса до отображения в HTML. Аналогично с регистро-зависимой системой: везде будет только исходный регистр (для корректности), каждая регистро-независимая операция должна сама обработать регистр.

То есть противоположность удобной потери детали (регистра) — это не слегка неудобная деталь, а минное поле, усеянное этими мелкими деталями. Где выше шанс словить баг?

Это неуместное стремление к техничности вида «я пишу на сборке из ДСП» вместо «я пишу на столе».

Пусть пишут Харе Кришна, Харе Рама 400 раз, для начала. Винда это помойка головного мозга.

Полный юникод вообще сложен везде, даже в такой простой операции как подсчёт символов. А на практике ASCII — это предсказуемый, привилегированный фундамент.

Файловая система должна быть двоично-безопасная. Есть символ с кодом 0, который завершает Си-строки в т.ч. в ядре, и есть символ '/' который разделитель частей пути - эти байты в именах файлов запрещены, всё остальное разрешено и никак не должно интерпретироваться драйвером файловой системы. Имя файла - абстрактная байтовая последовательность.

В твоей классификации это получается «регистро-зависимая», но я всё же акцентирую внимание на том, что понятие «регистр символов» вообще файловой системе не должно быть знакомо. Так же как и понятие кодировок (866, 1251, koi8, utf8 итд). Всё это, если нужно, можно реализовывать в юзерспейсных библиотеках для конкретных нужд (как например делает wine для запуска виндософта или архиваторы для переносимости архивов между разными ОС).

C этим на винфак. Это у них там идиотизм с регистронезависимостью, почему-то обратный слэш используется в качестве разделителя элементов пути к файлу, да ещё и какие-то «буквы дисков» есть. Вот пусть вендузятники и объясняют почему у них всё настолько через жопу.

Или программа читает файл settings.json, который пользователь назвал Settings.json.

И что дальше? Если он файл решит Setting.jsons назвать (в рамках некоего допущения это будет даже логично) нам тоже начать угадывать что же на самом деле этот добрый человек имел в виду? Ни к чему хорошему это не приведёт.

Хочешь найти текстовые файлы? Будь добр, пиши .[Tt][Xx][Tt]$. Или .(txt|TXT)$, получая ясность в жертву корректности? Что делать с этим в код-ревью? Добавить ещё обработку пробелов в конце строки? В итоге мы ушли в куда-то далеко от простой идиомы .txt$.

Какая-то искусственная проблема, find -iname, if file.extension.to_lower() == 'txt', ну и т.п.

Алсо тут на сцену врываются врываются t×t, tⅹt, tｘt, ᵗˣᵗ ну и так далее

Чем больше свободы пользователю, тем лучше. Назвать файл CON, запихать в имя обратные слеши и вертикальные табуляции, создать рядом File_A и file_a - это всё свобода.

А то, что у Говнокодера Вебмакакиевича Криворученко файл на ext4 не находится, потому что регистр в путях не совпал, - это баг, который надо чинить в программе, а не путем фашизации ФС.

Хочешь найти текстовые файлы? Будь добр, пиши .[Tt][Xx][Tt]$. Или .(txt|TXT)$, получая ясность в жертву корректности? Что делать с этим в код-ревью? Добавить ещё обработку пробелов в конце строки? В итоге мы ушли в куда-то далеко от простой идиомы .txt$.

мантра «название файла - это набор байт и нечего тут обсуждать» на самом деле переводится следующим образом: «чет не охото с этим возиться, да еще потребители сценариев не накидали - оставим проблему следующему поколению». И оно в итоге действительно «стреляет», к примеру, кто-то (как у же было сказано - укурки) в стандарте POSIX написал, что -i у grep - это опция (-i: Perform a case-insensitive search) и теперь постоянно приходится с этим мучаться, вот, серьезно, не могу припомнить, когда бы я запускал grep без -i, ровно как и find всегда запускается с -iname а не с -name. При этом есть-таки разработчики, которые мыслят в этом вопросе достаточно трезво, например:

Working on fixing issue #3224 caused me to notice that searching history is case sensitive. So history –search wtf is not the same as history –search WTF. Not very friendly, IMHO. I propose changing the default to case insensitive searching with an option for case sensitive.

В итоге я установил fish на посмотреть - реально удобный шел, непонятно зачем все время пользовался bash и zsh.

Конкретно у пользователя в случае работы с текстовой информацией потребность в использовании верхнего регистра появляется исключительно в момент, когда пользователю нужно подготовить «документ» или что-то очень сильно напоминающее «документ», т.е. тогда, когда верхний регистр служит для выделения предложений или определенных слов в предложении. В остальных случаях регистр попросту игнорируется, представьте, чтобы было бы, если бы UI разрабатывали те же укурки, что и стандарт POSIX: нужно было бы на Ctrl+F еще постоянно указывать хотим мы искать с учетом регистра или нет - это же дичь, однако в случае less или vi этим постоянно приходится заниматься: less запускать с -i, ровно как и grep, с vi совсем беда - :set ic на замену тоже влияет, что нежелательно, поэтому приходится вместо /smth писать /\csmth - вот неудобно же :( Из довольно забавного: браузеры по Ctrl+F вполне находят также и умляуты, что вполне ожидаемо, а вот MS Word - уже нет, в vi и less - уже ожидаемо нет.

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

Почему файловые системы в Linux не должны следовать этим же принципам и быть удобными в первую очередь для пользователей, а не для программ - совершенно непонятно. Если программа самостоятельно какие-то файлы создает, то по какой причине ей может понадобиться в одной директории создавать два файла с условно одинаковыми названиями? Я навскидку могу только два сценария придумать:

• у MySQL название файлов совпадает с названиями соответствующих таблиц, а таблицы можно в разном регистре заводить (зачем, правда, не ясно) - совершенно определенно это ошибка в дизайне
• хочется получить странное: ограничить допустимую длину названий файлов, но при этом расширить допустимый алфавит (получить что-то в духе content-addressable database)

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

Если

мне-то все давно понятно.

Так

Поделитесь мнением: что/как/для чего/лучше/хуже/правильно/неправильно итд

мало того что запутанная из за объема юникода, так еще и зависит от локали

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

сложно было дочитать до конца? :o)

я завел эту тему, что-бы продолжить обсуждение тут а не в «офтоп-теме».
т.е то, что вы «тут обьясняете», вы объясняете, по сути, не мне, а «сообществу»

Будет как в анекдоте про ученика «я четыреста раз написал ‘пошёл домой’ и пашол дамой» :))

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

Декларативность. Какая проблема решается? Символической ссылки или то что данные записаны не в тот «файл»?

Уязвимость кроется в устройстве файловых систем на машинах клиентов. Так, ФС, не различающие (или нормализующие) регистр символов, подвержены атакам: NTFS, FAT на Windows и HFS+ на Mac OS X.

Получается очередной аргумент против регистронезависимых ФС: это дополнительный источник уязвимостей и атак.

Проблема высосана, всем будет достаточно RADIX-50.

запутанная из за объема юникода

Представил себе регистрозависимость для U+1F4A9, слегка поплохело.

Я бы выбрал регистрозависимые, но с запретом создавать такие же имена в другом регистре. Т.е. чтобы можно было создать только в одном варианте, создал ААА и чтобы АаА уже нельзя было создать, но доступ было только по ААА при этом. И строгость и отсутствие путаницы одновременно и автодополнение в терминале лучше работает.

EBCDIC!

понятие «регистр символов» вообще файловой системе не должно быть знакомо

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

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

Вот это как-то более похоже на правду звучит.

Это как со строковыми классами. В QtCore сделали QString как класс для прикладной работы со строками. Так же и CString у микрософта и ещё много у кого. А исходный std::string от Страуструпа-Степанова – это «чёт неохота с этим возиться, смотрите, как красиво и универсально, применили шаблоны к символьному типу и готово!»

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

Так я и говорю, раз ты просветился и всё знаешь, поделись истинными знаниями с сообществом.

А то получается: «Расскажи как оно устроено. Не, я и без тебя знаю как, но хочу тебя проверить, поэтому расскажи ты.».

Нет правильного и неправильного.

Есть факт, что некоторые Linux пакеты тупо не соберутся на регистронезависимой ФС (где-то в процессе сборки создаются файлы отличающиеся лишь регистром имени и если ФС не обрабатывает такое, то один перезаписывает другой и сборка падает).

Напротив, многий виндовой софт упадёт, если ФС регистрозависимая. Но Wine так и так эмулирует регистронезависимость, насколько я знаю.

Так что для Linux правильно использовать регистрозависимую ФС, иначе будет больно.

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

Но Wine так и так эмулирует регистронезависимость, насколько я знаю

делает он это очень плохо (впрочем как и Samba): на каждый ENOENT нужно делать readdir и проверять действительно путь отсутствует или нет. И даже собственный кеш реализовать толком нельзя - в ведре возможностей или не хватает или косые.

Файловая система очень сильно зависит от текстового представления.

Классика: ΚΟΣΜΟΣ <-> κόσμος, Maßstab

Ты уверен, что нужна такая регистронезависимость на уровне ФС?

Maßstab

Ты имел в виду, что ẞ официально признали лишь недавно и традиционно капсом принято писать MASSSTAB? Да, на уровне ФС такое безобразие точно не нужно.

Maßstab

Ты имел в виду, что ẞ официально признали лишь недавно и традиционно капсом принято писать MASSSTAB? Да, на уровне ФС такое безобразие точно не нужно.

И до этого были исправления правил. С учётом вариаций применения правил получить можно и так:

Maßstab -> MASZSTAB, MASS-STAB, MASSSTAB, MAẞSTAB

Юникод как раз таки о том, чтобы от локали не зависеть, ну по крайней мере не страдать как от запуска программы ожидающей всратый ja_JP.SJIZZ когда в системе не менее всратый ru_RU.KOI8-R.

Но таблица с casefolding там приличного размера. Ну и UTF-8 распарсить нужно.

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

(Никакой любви к коллегам по цеху, дада)

Wine, насколько я помню, все-таки старается кешировать. Собственно я это у него и подглядел, когда сам писал эмуляцию регистронезависимой виртуальной ФС с кешированием. Однако, полностью забил на юникод и эмулирую только латиницу. Но это просто задача не предполагает чего-то сложного и меняющегося находу, как в Wine.

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

opendir/readdir/closedir, кстати, классическое посиксовое говно. От ядра есть вызов getdents, который пишет в массив dirent-ов.

написаны оптимизированные под неё средства поиска

Вот средства поиска и должны знать, что A и a, O, o, О, о и 0, а также I, l и 1 с некоторой вероятностью могут рассматриваться как один символ.

Юникод как раз таки о том, чтобы от локали не зависеть

Ту путаешь таблицу символов и преобразование текста.

Почитай про Iıİi:

• I без точки
• I с точкой

И там хороший пример:

<td lang="en" style="font-size: 200%">I</td>
<td lang="en" style="text-transform: uppercase; font-size: 200%">i</td>
<td lang="tr" style="font-size: 200%">İ</td>
<td lang="tr" style="text-transform: uppercase; font-size: 200%">i</td>

Maßstab -> MASZSTAB, MASS-STAB, MASSSTAB, MAẞSTAB

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

Вообще, в этих наших компьютерах постоянно творится какая-то дичь. Есть чёрный ящик, есть белый ящик, а тут впору вводить новый термин — мутный ящик. Частью работает как белый, частью как чёрный, а частью как белый, но врёт, падлюка.

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

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

Если взглянуть на проблему чуть глубже и чуть абстрактнее… Зачем человечеству вообще нужны 2 регистра для одних и тех же букв?! Хорошо ещё не 3 регистра и не больше…

Мне кажется, от второго регистра вообще бы стоило отказаться.

Регистронезависимая FS - это пережиток FS с кодировкой RADIX-50. В остальных случаях использование «костылей» для приведения к одному регистру (а также приведения é,ê,è,ë к e и т.п., ещё можно болгарскую кириллическую кодировку вспомнить, где добавлены только отличающиеся по написанию от латиницы буквы) нестабильно, чревато ошибками и уязвимостями.

Простое и однозначное лучше сложного и хитровыделанного. Соответственно, на мой взгляд, ФС должна быть только регистро-зависимой. Регистро-независимые не нужны.

где-то в процессе сборки создаются файлы отличающиеся лишь регистром имени

Вот мне кажется, что создавать такие файлы – неправильно. Вне зависимости от того, какая ФС. Это и вообще способствует путанице.

некоторые Linux пакеты

Что за пакеты, например?