Discussion :

[Mathis Lucas]

Linus Torvalds exprime son mécontentement à l'égard des systèmes de fichiers insensibles à la casse : « les noms insensibles à la casse sont terriblement erronés »
mais certains ne partagent pas son avis

Les travaux sur le noyau Linux 6.15 continuent de susciter des réactions brutales de la part de Linus Torvalds. Il a précédemment exprimé sa frustration à propos de certaines sections du code de test qui ont ralenti le processus de construction dans la version 6.15-rc1 du noyau Linux. Puis, récemment, il a partagé son point de vue sur une idée controversée de longue date : les systèmes de fichiers insensibles à la casse. Et comme d'habitude, il ne s'est pas retenu. S'adressant au développeur du nouveau système de fichiers Linux Bcachefs, il a déclaré : « les noms insensibles à la casse sont terriblement erronés, et vous n'auriez pas dû les utiliser du tout ».

L'élément déclencheur immédiat a été un bogue découvert dans Bcachefs, un système de fichiers Linux relativement nouveau qui est en cours de préparation pour une utilisation courante dans le noyau. Le développeur de Bcachefs, Kent Overstreet, a introduit des modifications pour prendre en charge les noms de fichiers insensibles à la casse, mais ces changements ont entraîné des problèmes. Ce qui a visiblement déclenché la colère de Linus Torvalds.

À la suite des modifications introduites par Kent Overstreet, il a été découvert que sa prise en charge des cas de figure (la partie qui permet à un système de fichiers de traiter « File.txt » et « file.txt » comme un seul et même fichier) était défectueuse. Un correctif a été soumis pour le noyau Linux 6.15.

À première vue, il s'agit d'un simple rapport de bogue de routine. Mais pour Linus Torvalds, il ne s'agit pas d'un petit problème technique. Selon lui, il s'agit d'un symptôme d'un problème beaucoup plus profond que les développeurs de systèmes de fichiers ne cessent d'ignorer. Son argument principal : la normalisation de la casse ne devrait même pas exister. Le message de Linus Torvalds ne concernait pas seulement un bogue. Il s'agit de l'idée en elle-même.

La seule leçon à retenir est que les spécialistes des systèmes de fichiers n'apprennent jamais. Les noms insensibles à la casse sont terriblement erronés, et vous n'auriez pas dû les utiliser du tout. Le problème n'était pas l'absence de tests, le problème était de les mettre en œuvre dès le départ.

Le problème est ensuite aggravé par « le fait d'essayer de faire les choses correctement » et, ce faisant, de les faire horriblement mal, parce que le « bien » n'existe pas, mais essayer de le faire donnera aux octets aléatoires une signification très magique. Et puis, les tests sont tous complètement cassés de toute façon. Aux dernières nouvelles, ils n'ont pas testé tous les cas vraiment intéressants - ceux qui causent des problèmes de sécurité dans l'espace utilisateur.

Des problèmes de sécurité comme « l'espace utilisateur a vérifié que le nom de fichier ne correspondait pas à un motif sensible à la sécurité ». Et puis le système de fichiers de merde finit par correspondre à ce motif *de toute façon*, parce que les gens qui font de l'insensibilité à la casse *INVARIABLEMENT* font des choses comme ignorer les caractères non imprimables, de sorte que maintenant « insensible à la casse » signifie aussi « insensible à d'autres choses aussi ».

Selon Linus Torvalds, le problème ne réside pas uniquement dans l'absence de tests, mais dans une gestion inadéquate de ces derniers. Il a pointé du doigt le fait que certains cas de test cruciaux n'avaient pas été couverts, en particulier ceux susceptibles d'entraîner des problèmes de sécurité dans l'espace utilisateur.

Le problème de Bcachefs n'est pas non plus la première fois que les systèmes de fichiers Linux rencontrent des problèmes de normalisation de la casse. Par le passé, il y a eu des problèmes tels que le comportement de la normalisation de la casse avec les emojis et d'autres caractères Unicode spéciaux.

Les incohérences et les risques liés au standard informatique Unicode

La discussion déclenchée par le développeur du système de fichier Bcachefs a ravivé un débat plus large sur la pertinence des systèmes de fichiers insensibles à la casse. Certains membres de la communauté estiment que cette fonctionnalité (l'insensibilité à la casse) est nécessaire pour assurer la compatibilité avec des systèmes comme Windows, tandis que d'autres, comme Linus Torvalds, considèrent que cela introduit des risques de sécurité et de cohérence.

Linus Torvalds a mis en lumière certaines incohérences liées à Unicode et aux caractères non imprimables. Ces incohérences peuvent entraîner des erreurs de correspondance des noms de fichiers et, par conséquent, nuire à la fiabilité du système. Il souligne que les « points de code ignorables » d'Unicode peuvent faire en sorte que deux noms de fichiers apparaissent différents à un utilisateur, mais sont traités comme étant identiques par un système de fichiers.

Par exemple, les emojis ❤ et ❤️ sont deux caractères Unicode distincts, mais la normalisation naïve de la casse peut les traiter à tort comme identiques. Il a déclaré : « ainsi, chaque programme en mode utilisateur qui vérifie qu'il ne touche pas aux chemins spéciaux est susceptible d'être trompé et de faire des choses qu'il a explicitement vérifié qu'il ne devait pas faire. Et non, ce n'est pas quelque chose d'inhabituel ou d'étrange. Des tas de programmes font cela ».

Cependant, certains membres de la communauté ne partagent pas son avis. « Le problème est que l'insensibilité à la casse est gênante pour les codeurs, mais pratique pour les utilisateurs. Parfois, je trouve tout aussi pratique de taper "torvalds" que "Torvalds". Cela devrait-il désigner deux personnes différentes ? La sensibilité à la casse est un artefact de la manière dont les éléments du langage sont codés », a écrit un utilisateur. Il a ajouté :

Les systèmes de fichiers existent pour organiser, stocker et récupérer des données. Ils sont inutiles si les utilisateurs ne peuvent pas trouver ce qu'ils veulent dans une grande collection de fichiers. Vous savez ce qui permet de cacher les fichiers aux utilisateurs ? La sensibilité à la casse. Peu importe la supériorité technique de la sensibilité à la casse, si vous la défendez pour un système de fichiers exposé à l'utilisateur, vous avez tort.

Selon certains, l'opposition entre les partisans des systèmes de fichiers insensibles à la casse et leurs détracteurs est l'une des raisons pour lesquelles Linux peine à s'imposer sur le bureau. « Ni 2025 ni aucune autre année ne sera l'année de Linux sur le bureau. Linux est idéal pour les passionnés ou les environnements techniques spécialisés, mais sa communauté et ses développeurs comprennent mal les affinités des utilisateurs généraux », a écrit un critique.

Linus Torvalds souvent critiqué pour ses prises de position jugées brutales

Linus Torvalds est le créateur du noyau Linux et dirige la maintenance du projet depuis plus de 30 ans. Il est extrêmement investi dans la qualité et la stabilité du noyau Linux. Il considère que Linux doit être conçu de manière robuste et sans compromis sur la sécurité. Ainsi, lorsque des décisions sont prises concernant des changements dans le noyau (comme l'introduction de systèmes de fichiers insensibles à la casse), il les examine de manière rigoureuse.

Si une décision ne lui semble pas optimale ou risquée, il n'hésite pas à exprimer son mécontentement de manière forte. Mais son style de gestion est de plus en plus critiqué. À plusieurs reprises, il a été critiqué pour ses méthodes de communication qui peuvent être perçues comme agressives ou offensantes.

« Je respecte Linus Torvalds, mais sérieux, il me désespère dans sa façon de parler aux gens. Ça ne donne pas envie de contribuer », a écrit Metal3d, un lecteur de Developpez.com. Face aux critiques, Linus Torvalds a montré par le passé une volonté d'évoluer, notamment après avoir pris des pauses pour réfléchir à son comportement et à la façon de mieux interagir avec les membres de la communauté. Toutefois, rien n’a changé véritablement.

Dans le cas de l'introduction des systèmes de fichiers insensibles à la casse, Linus Torvalds a clairement exprimé sa frustration face à ce qu'il considère comme une mauvaise conception. Pour Linus Torvalds, ces choses sont faites sans tenir compte des conséquences à long terme. Il voit ces changements comme des erreurs qui peuvent entraîner des risques de sécurité et de fiabilité, et il souhaite que les décisions soient prises avec plus de prudence.

Source : Linus Torvalds

Et vous ?

Quel est votre avis sur le sujet ?
Que pensez-vous des systèmes de fichiers insensibles à la casse ?
Linus Torvalds affirme que cette fonctionnalité est terriblement erronée. Qu'en pensez-vous ?
Pensez-vous également que l'insensibilité à la casse introduit des risques de sécurité et de cohérence ?

Voir aussi

Linus Torvalds critique le code de test resté dans Linux 6.15-rc1 qui ralentit le processus de build : « N'obligez pas les autres à voir cette chose dégoûtante »

Le noyau Linux 6.14 est disponible avec un pilote NTSYNC fonctionnel destiné à améliorer les performances des jeux Windows sur Linux fonctionnant avec Wine et un meilleur équilibrage des lectures Btrfs RAID1

L'un des responsables de la maintenance du noyau Linux Rust se retire du projet, invoquant des "absurdités non techniques"

Linus Torvalds : « Vos limitations matérielles ne devraient pas être un problème pour le reste d'entre nous », le père de Linux fustige les partisans de la limite de 80 caractères par ligne de code

[GLDavid]

Bonjour

Ca me rappelle ce meme:

Pour être honnête, je suis plutôt Team Linus. Windows a cette habitude de ne pas être sensible à la casse, ce qui m'a conduit plusieurs fois à des confusions. Ok, c'était pas sur des choses sensibles mais quand même.
Je préfère que l'OS me dise "Désolé, mais je connais pas cette adresse".
Just my 2 cents!

@++

[phsenaux]

En réalité, le plus grand risque de l'insensibilité à la casse est l'utilisation de caractères "exotiques".
Les seuls caractères à casse sont les lettres de l'alphabet (éventuellement accentuées), et c'est tout.
Mais effectivement, l'utilisateur ne fait pas attention entre majuscule et minuscule.
Et donc un utilisateur ne voudra pas d'un système sur lequel il ne retrouvera pas ses fichiers. Tchao Linux. Il faut aussi se poser la question de pourquoi les gens continuent à payer pour Windows malgré les immenses progrès UI de Linux.
En réalité, la sensibilité à la casse est la facilité : chaque code caractère est considéré différent d'un autre : c'est le fonctionnement de base de l'utilisateur, pas de l'humain.
Alors, forcément, c'est plus secure, puisqu'il n'y a aucune interprétation.
Mais maintenant même l'IA gère majuscules et minuscules.
Après, tout dépend à quel niveau est mis la limite : on interdit les noms identiques mis en minuscule, on permet au système de rechercher sans casse, ...
Linus a peut-être une vision vieille de 20 ans, et ceci explique aussi la faible présence de Linux hors serveurs (côté serveur, LINUX n'a fait que remplacer UNIX, donc rien d'extraordinaire).

[smarties]

L'utilisateur lambda va rarement utiliser la ligne de commande : depuis l'explorateur graphique il clique la plupart du temps. S'il saisit le chemin, il y a généralement de la complétion pour l'aider.

[fredix69]

Si les gens veulent un OS débile il existe Windows pour ça !
Sérieusement il faudrait niveler par le bas l'OS pour toucher le grand public ??
L'insensibilité à la casse c'est clairement la porte ouverte à des failles de sécurités et malwares.
De plus l'utilisateur lambda utilise l'explorateur de fichiers qui l'aidera à retrouver ses fichiers quelque soit la casse.

Quant au caractère de Linus, il ne faut pas oublier que ses décisions peuvent impacter toute la tech du monde entier ... Il ne fait pas de la politique hein, il est dans le concret et fait un travail remarquable pour le bien commun.
Alors s'il peut paraître rude c'est qu'on ne fait pas n'importe quoi dans le kernel..

[NotABread]

Pour le coup, team linux pour trois raison:
- En tant qu'utilisateur classique, je suis agacé de devoir renommer en deux temps un dossier pour avoir la bonne casse. Plus d'une fois, il m'est arrivé que renommer quelque chose comme "Monprojet" en "MonProjet" requière de passer par un nom intermédiaire car le système, voyant que les noms sont "les mêmes", n'a pas procédé au changement
- D'un point de vue stabilité/sécurité, il n'y pas pas que les lettres latines à gérer et plein de symbole se ressemble (comme relevé par l'article). Un petit oublie ou une différence d'interprétation pourrait avoir de grande conséquence
- D'un point de vue code, "Toto" est différent de "toto". Cela alourdie fatalement toutes manipulation de fichier (que ça soit passer par une abstraction ou convertir la case avant chaque comparaison)

Je trouve que ça amène beaucoup de complication pour un confort très circonstanciel. La complétion dans les UI et les terminaux est bien plus pratique et réduit les accros dû à la case

[Fagus]

Bcachefs : non mais déjà qui utilise ce système de fichiers ? La dernière fois que j'ai installé du debian, c'était sur le vénérable ext4. En théorie, btrfs est carrément supérieur, mais il n'est pas encore ni recommandé, ni par défaut (en debian) donc j'ai eu la trouille d'avoir des problèmes d'utilisateur précoce. Je ne l'utilise que sur les disques de sauvegarde (pour la compression native).

Ensuite, je pense aussi que c'est de la folie d'implémenter dans le système de fichier l’insensibilité à la case, pour un OS et tout un écosystème qui présuppose la sensibilité à la case. ça va ouvrir des tonnes de bugs non-testés.
Si c'est pour la compatibilité avec windows, windows n'utilisera jamais Bcachefs, mais NTFS ou un FAT.

Et pour quoi faire ? les explorateurs de fichiers implémentent déjà la recherche insensible à la case.
Le terminal par contre... ça me choquerait pas que quand il ne trouve pas un fichier, il me fasse une suggestion si j'ai fait une erreur de case.

[Aure7780]

Si les gens veulent un OS débile il existe Windows pour ça !
Sérieusement il faudrait niveler par le bas l'OS pour toucher le grand public ??
L'insensibilité à la casse c'est clairement la porte ouverte à des failles de sécurités et malwares.

Tu en as oublié un que portant beaucoup de personnes trouve bien : MacOS ! est aussi insensible à la case...

C'est fou comment les 2 OS les plus populaires au monde ont tous les deux un FS insensible à la casse.

Je suis pour la team case sensitive, vu le nombre de problème qu'il peut y avoir quand on fait du développement multiplateforme...

[foetus]

En théorie, btrfs est carrément supérieur, mais il n'est pas encore ni recommandé

cela me fait toujours rire : Btrfs, ZFS, ReiserFS, ... et pour Windows WinFS tous ces systèmes de fichier révolutionnaires, qui sont géniaux mais toujours en projet ou abandonné.

Il n'y a que Mac, OS X/ Apple, qui a réussi avec HFS+ Apple File System (*) qui permet les métadonnées, les liens et la compression (entre autres). Pas comme ces 2 "trucs assez pourris/ basiques" que sont NTFS et ext

*: @Christophe me signale que je me suis trompé de FS

[Psycrow]

La sensibilité à la casse ne rend pas les choses difficiles, c'est un sujet qui peut rester propre au système de fichier et être abstrait par une bonne implémentation des outils, e.g. la recherche de fichier qui passe le motif et les cibles tout en minuscule, "enlève"/ignore les accents et autre caractères spéciaux.
Du coup le système de fichier reste sensible à la casse et imperméable aux attaques spécifiques, mais l'utilisateur en est grandement abstrait. Enlever la sensibilité à la casse revient à forcer les petites roues sur un vélo, certes c'est plus facile pour l'utilisateur lambda, mais ça limite grandement tous les autres, et ça peut causer des accidents.

Et pour répondre à un autre utilisateur, MacOS donne le choix sur la sensibilité à la casse au moment de formater un volume, on est loin du monolithe idiot de Microsoft.

[Christophe]

tous ces systèmes de fichier révolutionnaires, qui sont géniaux mais toujours en projet ou abandonné.

ZFS et BtrsFS ne sont pas du tout à l'abandon.

Il n'y a que Mac, OS X/ Apple, qui a réussi avec HFS+ qui permet les métadonnées, les liens et la compression (entre autres)

HFS+ est depuis un moment remplacé par APFS, qui permet le copy-on-write, les snapshots tout comme BTRFS il me semble. ZFS permet également les snapshots (pour le COW, je ne sais pas).

[kain_tn]

Tu en as oublié un que portant beaucoup de personnes trouve bien : MacOS ! est aussi insensible à la case...

C'est fou comment les 2 OS les plus populaires au monde ont tous les deux un FS insensible à la casse.

Je suis pour la team case sensitive, vu le nombre de problème qu'il peut y avoir quand on fait du développement multiplateforme...

Exactement.

D'ailleurs, même Windows est partiellement sensible à la casse: en fait, NTFS supporte le "case sensitive".

Android (75% de parts de marché, quand-même, donc les gens ne doivent pas trouver ça si difficile), est sensible à la casse pour le stockage interne (ext4) et insensible à la casse sur les supports amovibles (parce qu'en général, c'est du ExtFAT, et donc il se traine les limitations débiles du FAT de MSDOS).

Rendre un système insensible à la casse, c'est donner de mauvaises habitudes aux utilisateurs. Pourquoi ne pas rendre les mots de passe insensibles à la casse aussi, tant qu'à faire!

[fodger75]

Là c'est une grosse grosse bêtise de la part de Linus, heureusement que le système de fichier est insensible à la casse sinon bonjour les doublons, faux positifs, conflits ...

[OrthodoxWindows]

Rendre un système insensible à la casse, c'est donner de mauvaises habitudes aux utilisateurs. Pourquoi ne pas rendre les mots de passe insensibles à la casse aussi, tant qu'à faire!

Cela dit, naturellement, une majuscule est la même lettre qu'une minuscule, le premier réflexe de n'importe qui, c'est de ne pas faire la différence. Un informaticien va faire la différence car il a été conditionné à la faire.
Si le système de fichier est sensible à la casse, il devraient y avoir une correction automatique si un fichier avec un nom proche est détecté.
Quand aux mots de passe, il s'agit d'un cas particulier.

[kain_tn]

Cela dit, naturellement, une majuscule est la même lettre qu'une minuscule, le premier réflexe de n'importe qui, c'est de ne pas faire la différence. Un informaticien va faire la différence car il a été conditionné à la faire.

N'importe quoi. Un ordinateur, ce n'est pas un grille-pain. On est en 2025. La plupart des personnes, y compris âgées en ont approché un. Et elles possèdent aussi un smartphone. Il faut arrêter de prendre les utilisateurs finaux pour des idiots.

Si le système de fichier est sensible à la casse, il devraient y avoir une correction automatique si un fichier avec un nom proche est détecté.

Et puis quoi encore? Ce serait une idée encore plus stupide que de rendre le système de fichier insensible à la casse. Implémenter un truc qui change les mots que l'on tape, à la manière d'un correcteur d'orthographe, juste pour la paresse de certains: vous imaginez le cauchemar pour la plupart des utilisateurs?

Quand aux mots de passe, il s'agit d'un cas particulier.

Et ce serait tout aussi stupide de les rendre insensibles à la casse sous prétexte que l'on prend les utilisateurs pour des idiots incapables de s'adapter.

[Christophe]

une majuscule est la même lettre qu'une minuscule

Ben non sinon on ne les utiliseraient pas. Le fait de ne pas mettre de majuscules ne va pas empêcher un humain de comprendre le texte. Par contre pour un ordinateur, un caractère correspond à une valeur numérique, différente pour chaque caractère minuscule, majuscule, inconnu de notre alphabet (caractères d'autres alphabets, sans compter les langages à idéogrammes).

J'ai connu des systèmes limitées à 8 caractères + 3 pour l'extension. Avec la puissance des ordis de maintenant par rapport à cette époque, ou on ne travaille plus en ASCII 7 bits (avec des pages de codes) mais en UTF-8, pourquoi rendre un système insensible à la casse, et du coup comment un tel système pourrait gérer les caractères cyrilliques, chinois ,etc ?

[wiztricks]

Ben non sinon on ne les utiliseraient pas.

Une même lettre (A par exemple) peut être représentée par des caractères majuscule ou minuscule (et éventuellement titre).

Pour les langues "sans", c'est "facile" à gérer en posant majuscule(x) = minuscule(x) = x.
Mais on a toujours des cas particuliers comme le ß allemand qui sera (pas toujours) SS en majuscule et deviendrait ss en minuscule.

On a aussi des dépendances sur la langue où par exemple I majuscule n'est pas le même en français (I) qu'en turc (İ).

Vaste sujet à traiter pour un éditeur de texte, mais pour ce qui est des noms de fichiers, compliqué de faire "bien".

De plus, si on considère un nom de fichier comme un mot (ou une suite de mots) d'un langage, la recherche d'un mot devra sans doute être insensible à la casse (exemple pour compter le nombre d'occurrences de "pomme" dans un texte, sans oublier "Pomme").

Par contre, le nom d'un fichier est un identifiant même si on va choisir des "mots" qui nous parlent, segmenter le nom (par exemple date-heure-libellé.ext).

Du coup, pour moi, Linus à raison: techniquement c'est bien trop compliqué et les noms de fichiers sont des identifiants pas du texte.

- W

[sylvain1984]

Bonjour Foetus,

cela me fait toujours rire : Btrfs, ZFS, ReiserFS, ... et pour Windows WinFS tous ces systèmes de fichier révolutionnaires, qui sont géniaux mais toujours en projet ou abandonné.

En fait il n'y a pas un FS optimal pour tous les usages. Raison pour laquelle, à mesure que les connaissances et les techniques progressent, nos chercheurs en informatique continuent de proposer de nouveaux FS qui subissent la sélection naturelle, impitoyable...

Heureusement que nous n'en sommes pas resté aux FS historiques...