Ted ts'o, l'auteur des systèmes de fichiers ext2 / ext3 / ext4, a accepté la branche Linux-next, sobre la base à partir de laquelle la version Linux Kernel 5.2 sera créée, un ensemble de changements qui implémenter le support pour opérations de cas indépendantes dans le système de fichiers Ext4.
Les patchs ils ajoutent également la prise en charge des caractères UTF-8 dans les noms de fichiers. Le mode de fonctionnement de la casse sans caractère est éventuellement inclus dans le lien vers des répertoires séparés à l'aide du nouvel attribut "+ F" (EXT4_CASEFOLD_FL).
Insensible à la casse pour ext4
Lorsque cet attribut est installé dans le répertoire, toutes les opérations avec les fichiers et sous-répertoires qui sont en elle ne sera pas sensible à la casse, y compris la casse sera ignoré lors de la recherche et de l'ouverture de fichiers (par exemple Test.txt, test.txt et test.TXT dans des répertoires similaires) seront considérés comme identiques).
Autrement dit, il correspond à une entrée de répertoire, même si le nom utilisé par l'espace utilisateur n'est pas un octet pour octet qui correspond au nom du disque, mais est une version équivalente sensible à la casse de la chaîne Unicode.
Cette opération est appelée une recherche de nom de fichier insensible à la casse. La fonctionnalité est configurée comme un attribut d'inode appliqué aux répertoires et hérité par leurs enfants.
Cet attribut solo peut être activé sur des répertoires videss pour les systèmes de fichiers prenant en charge la fonction d'encodage, évitant ainsi la collision de noms de fichiers qui ne diffèrent qu'au cas par cas.
Par défaut, à l'exception des répertoires avec l'attribut "+ F", le système de fichiers est toujours sensible à la casse. Pour contrôler l'inclusion du mode insensible à la casse, un ensemble modifié d'utilitaires e2fsprogs est fourni.
Ce correctif implémente la prise en charge réelle des recherches de noms de fichiers insensibles à la casse dans ext4, en fonction du bit de fonctionnalité et du codage stockés dans le superbloc.
Un travail qui a mis du temps à arriver
Les patchs ont été préparés par Gabriel Krisman Bertazi, contributeur Collabora et ont été tirés de la septième tentative après trois ans d'élaboration et de suppression des commentaires.
L'implémentation ne modifie pas le format de stockage sur disque et fonctionne exclusivement au niveau de la modification de la logique de comparaison de noms dans la fonction ext4_lookup () et du remplacement du hachage dans la structure dcache (Directory Name Lookup Cache).
La valeur de l'attribut "+ F" est stockée dans les inodes des répertoires individuels et s'applique à tous les fichiers et sous-répertoires attachés. Les informations de codage sont stockées dans le superbloc.
Pour l'instant, les recherches négatives ne sont pas poussées dans le dcache, car elles devraient de toute façon être invalidées, car nous ne pouvons pas faire confiance aux fichiers manquants.
Ceci est mauvais pour les performances, mais nécessite une certaine exploitation de la couche vfs pour être corrigé.
Nous pouvons vivre sans pour le moment, comme tout le monde.
Pour éviter les collisions avec les noms des fichiers existants, l'attribut "+ F" ne peut être défini que sur des répertoires vides dans les systèmes de fichiers, dans lequel le mode de prise en charge Unicode dans les noms de fichiers et de répertoires est activé pendant la phase de montage.
Les noms des éléments d'annuaire pour lesquels l'attribut "+ F" est activé sont automatiquement traduits en minuscules et reflétés de cette manière dans dcache, mais ils sont stockés sur disque sous la forme initialement définie par l'utilisateur.
Les nouveaux hachages de disque sont calculés comme le hachage de la chaîne entière de cas, plutôt que comme la chaîne directement.
Autrement dit, malgré le traitement du nom quel que soit le cas, les noms sont affichés et enregistrés sans perdre d'informations sur la casse des caractères (mais le système ne vous permettra pas de créer un nom de fichier avec les mêmes caractères, mais dans un cas différent).
Il permet également au code VFS de trouver rapidement l'entrée correcte dans le cache même si une chaîne équivalente a été utilisée dans une recherche précédente