Ton commentaire a achevé de me convaincre, j'étais plutôt sceptique au départ (dans le sens, pas convaincu plus par l'un ou l'autre système pour l'utilisateur de base), mais après avoir lu certains commentaires plus haut et le tien, je pense que peu de chose justifie vraiment qu'un système de fichier ignore la casse.
Si on passait notre temps en tant qu'utilisateur à sauvegarder des fichiers avec le même nom mais une casse différente, ça serait effectivement emmerdant (se retrouver avec deux fichiers toto et Toto), mais ce genre de cas se présente tellement rarement que j'ai effectivement du mal à admettre que la gestion case insensitive puisse être techniquement justifiable (et à bien y réfléchir, le logiciel de sauvegarde pourrait même agir de façon singulière dans ce genre de cas).
En fait, j'ai même plus généralement du mal à imaginer des cas où avoir "Toto" et "toto" dans le même répertoire serait problématique pour l'utilisateur, ergonomiquement parlant.
Au niveau linguistique et sémantique, je n'ai jamais été convaincu par les langages non sensibles à la casse comme Pascal ou Basic, car ça limite le champs des possibilités (nommer une classe "Classe" et une variable d'instance "classe" par exemple) tout en permettant de voir des horreurs (BEGIN et Begin ou begin dans le même code), et je me demande si du coup les mêmes limites ne s'appliquent pas au nommage de fichiers (impossibilité d'utiliser une nomenclature particulière pour les répertoires et les fichiers).
Maintenant, il est certain que le monde des applications Windows a pris de telles habitudes (il suffit juste d'imaginer une procédure d'un installeur de programme qui écrase une dll par une nouvelle sans faire gaffe à la casse dans un contexte case-sensitive pour imaginer les dégâts…) qu'il me semble impossible de revenir en arrière.
[^] # Re: Caractères ASCII
Posté par Guillaume Denry (site web personnel) . En réponse au journal Canonical embrasse la technologie Microsoft (bootloader). Évalué à 3.
Ton commentaire a achevé de me convaincre, j'étais plutôt sceptique au départ (dans le sens, pas convaincu plus par l'un ou l'autre système pour l'utilisateur de base), mais après avoir lu certains commentaires plus haut et le tien, je pense que peu de chose justifie vraiment qu'un système de fichier ignore la casse.
Si on passait notre temps en tant qu'utilisateur à sauvegarder des fichiers avec le même nom mais une casse différente, ça serait effectivement emmerdant (se retrouver avec deux fichiers toto et Toto), mais ce genre de cas se présente tellement rarement que j'ai effectivement du mal à admettre que la gestion case insensitive puisse être techniquement justifiable (et à bien y réfléchir, le logiciel de sauvegarde pourrait même agir de façon singulière dans ce genre de cas).
En fait, j'ai même plus généralement du mal à imaginer des cas où avoir "Toto" et "toto" dans le même répertoire serait problématique pour l'utilisateur, ergonomiquement parlant.
Au niveau linguistique et sémantique, je n'ai jamais été convaincu par les langages non sensibles à la casse comme Pascal ou Basic, car ça limite le champs des possibilités (nommer une classe "Classe" et une variable d'instance "classe" par exemple) tout en permettant de voir des horreurs (BEGIN et Begin ou begin dans le même code), et je me demande si du coup les mêmes limites ne s'appliquent pas au nommage de fichiers (impossibilité d'utiliser une nomenclature particulière pour les répertoires et les fichiers).
Maintenant, il est certain que le monde des applications Windows a pris de telles habitudes (il suffit juste d'imaginer une procédure d'un installeur de programme qui écrase une dll par une nouvelle sans faire gaffe à la casse dans un contexte case-sensitive pour imaginer les dégâts…) qu'il me semble impossible de revenir en arrière.