Comment les systèmes de fichiers insensibles à la casse affichent-ils les noms de fichiers en majuscules et en minuscules?


12

Cette question m'est venue l'autre jour lorsque je travaillais sur un projet de développement qui s'appuie sur un cadre d'opinion en ce qui concerne les noms de fichiers. Le cadre (non pertinent ici) voulait voir les noms de fichiers en majuscules en premier. Cela m'a fait réfléchir.

Sur un système de fichiers insensible à la casse, disons extFAT ou HFS + (spécifiquement non sensible à la casse) comment le système de fichiers permet-il d'accéder au même fichier avec les versions majuscules et minuscules du nom de fichier.

Par exemple:

$ 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

Toutes ces commandes seront résolues dans le même répertoire. Ce comportement, en particulier la sortie d' pwdune fonction bashdans ce cas, me montre-t-il simplement ce qu'il pense que je veux voir?

Un autre exemple:

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

Le système de fichiers signale ici le cas du nom de fichier d'origine tel que créé par l'utilisateur ou le programme.

À quel stade de la pile du système de fichiers le nom de fichier lisible par l'homme est-il conservé tel qu'il a été créé (par exemple, majuscules et minuscules) afin qu'il puisse être consulté par n'importe quelle combinaison des caractères ASCII en majuscules et en minuscules corrects? Est-ce juste une astuce regex quelque part ou y a-t-il autre chose qui se passe?

EDIT: Il semble que le comportement que je suis curieux de savoir se trouve dans cas préservant les systèmes de fichiers insensibles à la casse après quelques recherches ...


Ne pas écrire ceci comme réponse parce que je ne sais plus avec certitude mais je crois que vous ne pouvez pas avoir ~ / Documents et ~ / documents dans ce système de fichiers. Mais lorsque vous cd ~ / Documents ou ~ / documents, vous allez au même endroit et votre shell "joue bien" en se souvenant de ce que vous avez tapé. L'autre côté est que certains FS stockent la façon dont ils ont été créés dans un Aux. morceau de données. Par exemple, stocker ~ / Documents dans une table de recherche mais écrire dans le FS sous ~ / documents. Fondamentalement, créant une illusion que le système de fichiers se soucie de la casse lorsqu'il ne le fait pas.
coteyr

D'après ce que j'ai observé, dans le cas où un répertoire contient deux noms de fichiers identiques à l'exception de la casse, les systèmes de fichiers non sensibles à la casse peuvent répondre à une demande pour un fichier donné en en sélectionnant arbitrairement un. De telles situations peuvent survenir si les règles de conversion en majuscules / minuscules changent après la création d'un fichier.
supercat

Informations intéressantes sur la protection de la nature de NTFS: superuser.com/questions/364057/why-is-ntfs-case-sensitive
Canadian Luke

Réponses:


14

Un système de fichiers insensible à la casse signifie simplement que chaque fois que le système de fichiers doit demander "A fait-il référence au même fichier / répertoire que B?" il compare les noms des fichiers / répertoires en ignorant les différences en majuscules / minuscules (exactement ce qui compte les différences majuscules / minuscules dépend du système de fichiers - ce n'est pas évident une fois que vous avez dépassé ASCII). Un système de fichiers sensible à la casse n'ignore pas ces différences.

Un système de fichiers respectant la casse stocke les noms de fichiers comme indiqué. Un système de fichiers ne respectant pas la casse ne le fait pas; il convertit généralement toutes les lettres en majuscules avant de les stocker (théoriquement, il pourrait utiliser des minuscules, ou le cas de RaNsOm NoTe, ou autre, mais AFAIK tous ceux du monde réel utilisaient des majuscules).

Vous pouvez combiner ces deux attributs dans n'importe quelle combinaison. Je ne sais pas si vous pouvez trouver des systèmes de fichiers ne respectant pas la casse, mais vous pouvez certainement en créer un. Cependant, toutes les autres combinaisons existent ou existaient dans des systèmes réels.

Un système de fichiers respectant la casse et ne respectant pas la casse (le type de système de fichiers le plus courant ne respectant pas la casse de nos jours) stockera et renverra les noms de fichiers dans la majuscule que vous avez créée ou renommée pour la dernière fois, mais lors de la comparaison de deux noms de fichiers (pour vérifier si un existe, pour en ouvrir un, pour en supprimer un, etc.) il ignorera les différences de casse.

Lorsque vous utilisez un système de fichiers sensible à la casse sur un système Unix, divers utilitaires vont faire des choses étranges parce que Unix utilise traditionnellement des systèmes de fichiers-donc sensibles à la casse , ils ne sont pas attendre Document1et document1d'être le même fichier.

Dans le pwdcas, ce que vous voyez, c'est que par défaut, il sort simplement le chemin que vous avez réellement utilisé pour accéder au répertoire. Donc, si vous y êtes arrivé via cd DirName, il sera utilisé DirNamedans la sortie. Si vous y êtes arrivé via DiRnAmE, vous verrez DiRnAmEdans la sortie. Bash fait cela en gardant une trace de la façon dont vous êtes arrivé à votre répertoire actuel dans la $PWDvariable d'environnement. Il s'agit principalement de liens symboliques (si vous êtes cddans un lien symbolique, vous verrez le lien symbolique dans votre pwd, même s'il ne fait en fait pas partie du chemin d'accès à votre répertoire actuel). Mais cela donne également le comportement quelque peu étrange que vous observez sur les systèmes de fichiers insensibles à la casse. Je soupçonne que pwd -Pcela vous donnera le nom du répertoire en utilisant le cas stocké sur le disque, mais je n'ai pas testé.


J'aurais peut-être su que tu m'as battu contre celui-ci! (a voté)
Fabby
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.