Як файлові системи, нечутливі до регістру, відображають імена верхнього та нижнього регістрів файлів?

Це питання виникло у мене днями, коли я працював над проектом розробки, який спирається на обґрунтовану основу щодо імен файлів. Рамка (тут не має значення) хотіла бачити найголовніші назви файлів. Це змусило мене задуматися.

На регістронезавісімого файлової системи, скажімо , 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? Це просто трюк з регулярними виразками чи десь відбувається щось інше?

EDIT: Це схоже на поведінку мені цікаво зустрічається в разі зберігають регістронезавісімого файлових систем після більш деяких досліджень ...

filesystems filenames case-sensitivity

— 111 ---
джерело

Не пишу це як відповідь, тому що я вже точно не знаю, але вважаю, що у цій файловій системі ви не можете мати / / Документи та ~ / документи. Але коли ви cd ~ / Documents або ~ / dokuments збираєтеся там же, і ваша оболонка «грає добре», згадуючи, що ви ввели. Інша сторона полягає в тому, що деякі FS зберігають так, як це було створено в допоміжних системах. шматок даних. Наприклад, зберігання ~ / Документів у таблиці пошуку, але запис у FS як ~ / документи. В основному створюється ілюзія, що файлова система піклується про корпус, коли цього немає.

— coteyr

З того, що я зауважив, у випадку, якщо каталог містить два імена файлів, які однакові, за винятком регістру, файлові системи, що не залежать від регістру, можуть відповісти на запит для даного файлу, довільно вибравши один. Такі ситуації можуть виникнути, якщо правила перетворення верхнього / нижнього регістру змінюються після створення файлу.

— supercat

Класна інформація про природу збереження справи NTFS: superuser.com/questions/364057/why-is-ntfs-case-sensitive

— канадський Лука

Файлова система, що не враховує регістр, просто означає, що щоразу, коли файлова система повинна запитувати "чи A посилається на той самий файл / каталог, як B?" він порівнює назви файлів / каталогів, ігноруючи відмінності у верхньому / нижньому регістрі (саме те, що розраховано на великі / малі відмінності, залежить від файлової системи - це не очевидно, як тільки ви вийдете за межі ASCII). Файлова система, що враховує регістр, не ігнорує ці відмінності.

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

Ці два атрибути можна скласти в будь-яку комбінацію. Я не впевнений, чи зможете ви знайти файлові системи, що не зберігають регістр, але залежно від регістру, але ви, безумовно, можете створити цю. Хоча всі інші комбінації існують або існують у реальних системах.

Таким чином, файлова система, що не враховує регістр, файлова система (найпоширеніший тип файлової системи, нечутливої до регістру на сьогодні), зберігатиме та повертає імена файлів у будь-якій великій літери, яку ви створили або останньо перейменовували, але при порівнянні двох імен файлів (щоб перевірити, чи одна існує, щоб відкрити його, видалити його тощо), воно ігнорує відмінності у випадку.

Якщо ви використовуєте файлову систему, нечутливу до регістру, у вікні Unix, різні утиліти будуть робити дивні речі, оскільки Unix традиційно використовує файлові системи, що відрізняються від регістру, тому вони не сподіваються Document1і document1будуть тим самим файлом.

У pwdвипадку, що ви бачите, це те, що він за замовчуванням просто виводить шлях, який ви насправді використовували, щоб потрапити до каталогу. Тож якщо ви потрапили туди через cd DirName, він використовуватиме DirNameу висновку. Якщо ви потрапили туди через DiRnAmE, ви побачите DiRnAmEу висновку. Bash робить це, відслідковуючи, як ви потрапили до поточного каталогу в $PWDзмінній оточення. В основному це стосується символьних посилань (якщо ви перейдете cdна символьне посилання, ви побачите символьне посилання у вашому pwd, навіть якщо воно фактично не є частиною шляху до вашого поточного каталогу). Але це також дає дещо дивну поведінку, яку ви спостерігаєте у файлових системах, нечутливих до регістру. Я підозрюю, що pwd -Pдасть вам ім'я каталогу, використовуючи корпус, збережений на диску, але не перевірений.

— дероберт
джерело

Я, можливо, знав, що ти побив мене до цього! (upvoted)

— Fabby