Le case insensitives ne devrait pas être géré au niveau du système de fichier, comme la traduction des dossiers ou les fichiers cachés. Le faire au niveau du système de fichier ça pose des problèmes complexes à résoudre dans un tas de logiciel notamment pour les gestionnaires de versions (il faut vraiment faire gaffe avec svn pour renommer un fichier en changeant uniquement la casse de sont nom).
Ça tombe bien, NTFS est case-sensitive. C’est l’api windows qui s’occupe de faire la traduction (de même pour les noms de fichier 8.3, etc). Et c’est très possible de passer outre, en utilisant les APIs adaptées.
Je crois que FAT32 sous linux peut l’être aussi (case-sensitive). D’ailleurs, fondamentalement, un chemin n’est pas vraiment une « chaîne de caractères », c’est plutôt une suite d’octets sans signification particulière, et surtout sans notion d’encodage (donc fatalement, ça ne peut pas être insensible à la casse, notion qui n’existe pas à son niveau). Ça pose notamment plein de problèmes amusants quand cette suite d’octet est invalide dans l’encodage par défaut du système (ceux qui ont migré une machine du latin1 vers l’utf-8 doivent savoir de quoi je parle).
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: Linux power!
Posté par whity . En réponse à la dépêche Vulnérabilité dans Git et Mercurial sur certains systèmes de fichiers (FAT, NTFS, HFS+, etc.). Évalué à 6.
Ça tombe bien, NTFS est case-sensitive. C’est l’api windows qui s’occupe de faire la traduction (de même pour les noms de fichier 8.3, etc). Et c’est très possible de passer outre, en utilisant les APIs adaptées.
Je crois que FAT32 sous linux peut l’être aussi (case-sensitive). D’ailleurs, fondamentalement, un chemin n’est pas vraiment une « chaîne de caractères », c’est plutôt une suite d’octets sans signification particulière, et surtout sans notion d’encodage (donc fatalement, ça ne peut pas être insensible à la casse, notion qui n’existe pas à son niveau). Ça pose notamment plein de problèmes amusants quand cette suite d’octet est invalide dans l’encodage par défaut du système (ceux qui ont migré une machine du latin1 vers l’utf-8 doivent savoir de quoi je parle).
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0