Как нечувствительные к регистру файловые системы отображают имена файлов верхнего и нижнего регистра?

Этот вопрос возник у меня на днях, когда я работал над проектом развития, который опирается на укромную структуру в отношении имен файлов. Рамки (здесь неактуальны) хотели увидеть имена файлов в верхнем регистре. Это заставило меня задуматься.

В файловой системе, не учитывающей регистр, скажем, extFAT или HFS + (особенно нечувствительный к регистру), как файловая система обеспечивает доступ к тому же файлу с версиями имени верхнего и нижнего регистра имени файла.

Например:

$ cd ~/Documents $ pwd /home/derp/Documents $ cd ../documents $ pwd /home/derp/documents $ cd ../docuMents $ pwd /home/derp/docuMents $ cd ../DOCUMENTS $ pwd /home/derp/DOCUMENTS $ cd ../documentS $ pwd /home/derp/documentS 

Все эти команды будут разрешены в тот же каталог. Это поведение, в частности, выход из pwd только функция bash в этом случае просто показывает мне, что он думает, что я хочу видеть?

Другой пример:

 $ ls ~/Documents Derp.txt another.txt whatThe.WORLD 

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

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

Простите мое невежество, если это глупый вопрос (или их серия: p), но мне любопытно, что здесь происходит.

EDIT: похоже, поведение, о котором мне интересно, можно найти в файловых системах, не сохраняющих регистр, после нескольких исследований …

  • с учетом регистра gnu mv на Mac OS X
  • Сломанная труба при выходе grepping, но только с флагом -i
  • Неисправность регистра файловой системы OS X vlc
  • команды сортировки и uniq не работают, как ожидалось, когда выполняются cron
  • grep: игнорирование GREP_OPTIONS для поиска с учетом регистра
  • Использование шаблона в команде «ls» для поиска файлов, содержащих только прописные буквы
  • Как просмотреть имена файлов, чувствительных к регистру, для томов iso9660 / Joliet + UCS-3?
  • Удалить строку, содержащую нечувствительность к регистру
  • One Solution collect form web for “Как нечувствительные к регистру файловые системы отображают имена файлов верхнего и нижнего регистра?”

    Нечувствительная к регистру файловая система означает, что всякий раз, когда файловая система должна спрашивать: «А ссылается на тот же файл / каталог, что и B?» он сравнивает имена файлов / каталогов, игнорируя различия в верхнем / нижнем регистре (точно, что подсчет различий между верхним и нижним регистром зависит от файловой системы – это неочевидно, если вы выходите за пределы ASCII). Файловая система с учетом регистра не игнорирует эти различия.

    Файловая система, сохраняющая регистр, хранит имена файлов, как указано. Файловая система, не поддерживающая случай, не работает; он обычно будет преобразовывать все буквы в верхний регистр, прежде чем хранить их (теоретически, он может использовать строчные буквы или случай RaNsOm NoTe или что-то еще, но AFAIK использует все в реальном мире прописные буквы).

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

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

    Когда вы используете файловую систему без учета регистра в блоке Unix, различные утилиты будут делать странные вещи, потому что Unix традиционно использует чувствительные к регистру файловые системы, поэтому они не ожидают, что Document1 и document1 будут тем же самым файлом.

    В случае pwd вы видите, что по умолчанию он просто выводит путь, который вы фактически использовали для доступа к каталогу. Поэтому, если вы попали туда через cd DirName , он будет использовать DirName на выходе. Если вы попали туда через DiRnAmE , вы увидите DiRnAmE на выходе. Bash делает это, отслеживая, как вы попали в ваш текущий каталог в переменной среды $PWD . В основном это для символических ссылок (если вы cd в символическую ссылку, вы увидите символическую ссылку в вашем pwd , хотя на самом деле это не часть пути к вашему текущему каталогу). Но это также дает несколько странное поведение, которое вы наблюдаете на файловых системах, не учитывающих регистр. Я подозреваю, что pwd -P даст вам имя каталога, используя регистр, хранящийся на диске, но не протестировал.

    Linux и Unix - лучшая ОС в мире.