le système de fichiers insensible à la casse nous permet de résoudre les goulots d'étranglement importants pour les applications portées à partir d'autres systèmes d'exploitation
ne me touche pas et je ne comprends pas comment le processus de normalisation et de pliage nous permet d'optimiser notre stockage sur disque.
Wine, Samba et Android ont pour fournir une sémantique de système de fichiers insensible à la casse. Si le système de fichiers sous-jacent est sensible à la casse, chaque fois qu'une recherche sensible à la casse échoue, Wine et al. doit analyser chaque répertoire pour prouver qu'il n'y a pas de correspondances insensibles à la casse (par exemple, si vous recherchez /foo/bar/readme.txt échoue, vous devez effectuer une liste complète des répertoires et une comparaison de tous les fichiers dans foo/bar/* et tous les répertoires dans foo/* , et /* ).
Il y a quelques problèmes avec ceci :
- Cela peut devenir très lent avec des chemins profondément imbriqués (qui peuvent générer des centaines d'appels FS) ou des répertoires contenant des dizaines de milliers de fichiers (c'est-à-dire le stockage de sauvegardes incrémentielles via SMB).
- Ces vérifications introduisent des conditions de concurrence.
- C'est fondamentalement faux :si les deux
readme.txtetREADME.txtexistent mais une application demandeREADME.TXT, le fichier renvoyé n'est pas défini.
Android est allé jusqu'à émuler l'insensibilité à la casse en utilisant FUSE/wrapfs, puis le SDCardFS dans le noyau. Cependant, SDCardFS vient d'accélérer tout en déplaçant le processus dans l'espace du chenil†. Il devait encore parcourir le système de fichiers (et était donc lié aux entrées-sorties), introduisait des conditions de concurrence et était fondamentalement malsain. C'est pourquoi Google a financé† le développement d'une insensibilité native à la casse par répertoire dans F2FS et a depuis déconseillé SDCardFS.
Il y a eu plusieurs tentatives dans le passé pour activer les recherches insensibles à la casse via VFS. La tentative la plus récente en 2018 a permis de monter une vue insensible à la casse du système de fichiers. Ted Tso a spécifiquement cité les problèmes avec wrapfs pour ajouter cette fonctionnalité, car elle serait au moins plus rapide et (je crois) sans conditions de concurrence. Cependant, il n'était toujours pas solide (demande README.TXT pourrait renvoyer readme.txt ou README.txt ). Cela a été rejeté en faveur de l'ajout d'un support par répertoire pour l'insensibilité à la casse et il est peu probable qu'il soit jamais intégré à VFS††.
De plus, les utilisateurs s'attendent à une insensibilité à la casse, donc tout système d'exploitation orienté consommateur doit le fournir. Unix ne pouvait pas le prendre en charge de manière native car Unicode n'existait pas et les chaînes n'étaient que des sacs d'octets. Il existe de nombreuses critiques valables sur la façon dont le pliage de casse était géré dans le passé, mais Unicode fournit une fonction de pliage de casse immuable qui fonctionne pour tous sauf un seul paramètre régional (turc, et même dans ce cas, il ne s'agit que de deux points de code). Et le système de fichiers b-tree est le seul endroit raisonnable pour implémenter ce comportement.
†AFAICT
††J'ai envoyé un e-mail à Krisman, l'auteur des recherches insensibles à la casse basées sur VFS et de la prise en charge insensible à la casse par répertoire sur EXT4 et F2FS.
D'autres systèmes d'exploitation ont un système de fichiers insensible à la casse.
Par exemple :MacOS autorise la casse (par défaut) ou la casse. Adobe Photoshop et Adobe Lightroom ne fonctionnent pas bien avec le système de fichiers sensible à la casse. Cela signifie que dans les programmes Adobe, il existe probablement des chemins codés en dur, écrits de différentes manières (peut-être "Documents" et "documents" dans les différentes bibliothèques, ou juste parfois certains filtres sont appliqués (par exemple, les minuscules et la suppression des espaces, qui peuvent différer du chemin des données). Personne ne s'en souciait, car cela fonctionnait.
Donc, si maintenant vous voulez porter un programme conçu pour un système d'exploitation propriétaire commun de notre époque, soit vous devez corriger tous les chemins, de sorte que vous ayez toujours une utilisation cohérente des cas de noms de fichiers, soit vous préférez avoir un système de fichiers qui les gère pour vous.
Adobe ne pouvait pas le faire pour MacOS, alors attendez-vous à ce que les choses soient beaucoup plus difficiles (et coûteuses) pour les autres fournisseurs. Voir https://helpx.adobe.com/creative-suite/kb/error-case-sensitive-drives-supported.html