|
Sujet : Linux et case sensitive |
| Jak |
zeb2 a écrit a écrit :
Vrai. J'ai encore ma partition 98 et c'est comme ça. Ca masque meme les extensions par defaut, t'imagines le bordel : quand tu veux changer une extension, si tu rajoutes l'extension à la main, tu obtiens un fichier fichier.nouvelle_extension.ancienne_extension. Donc ça change rien :pt1cable:
Y a moyen de changer tout ça dans les préférences d'explorer, mais c'est chiant.
|
En fait, ça, ça le fait même encore maintenant dans Windows XP, et ça peut aussi se faire sous KDE et Gnome.
Le problème, c'est que c'est le mode par défaut, et c'est sujet à confusion (ben oui, on ne voit pas que le fichier attaché s'appelle en fait TOTO.JPG.exe, car les gens finalement ne font pas attention si ils voient TOTO.JPG, même si l'affichage qu'il devrait y avoir TOTO).
L'extension devrait TOUJOURS être affichée, je trouve. |
| philou_a7 |
(mode culture generale on)
@Kadreg : en fait c'est un poil plus compliqué que cela.
Historiquement, quand DOS effaçait un fichier, il remplaçait dans la fat le premier caractere du nom de fichier par un caractere "sigma" (j'me souviens plus de la valeur ASCII...) pour signifier que ce fichier etait effacé. Les valeur des zones du disque ou ce fichier etait stocké n'etaient pas effacées, et c'est sur ce principe que des utilitaires comme "undelete" fonctionnaient : on demande a l'utilisateur le premier caractere du fichier, on tente de recuperer les valeurs et on voit si ca marche ou pas. Si les donnees ont ete ecrasee ca vautre sinon c'est bon on a recuperé le fichier :p
Quand ils ont créé le systeme de noms longs pour Win95, ils ont détourné cette astuce de la façon suivante.
Un fichier est TOUJOURS stocké en 8.3 avec l'algo suivant :
- on garde les 6 premiers caracteres alphanumeriques du nom situés avant le premier '.' suivis de "~1" puis des 3 premiers caracteres alphanumeriques qui suivent le dernier '.' le tout converti en majuscules (toujours)
- si ce nom existe deja, on remplace le "~1" par "~2" et on essaie à nouveau
- au cas où, on va jusqu'a "~4"
- si ca marche toujours pas, on attribue les 6 premiers caracteres AU HASARD suivi de "~1", jusqu'a ce qu'on trouve un nom de fichier non utilisé dans le repertoire en cours. Comme le nombre maxi de fichiers d'un repertoire windows est inferieur aux nombre de combinaisons differentes de 6 caracteres alphanumeriques, on est assuré de pouvoir obtenir ce nom (sinon c'est une erreur de type "trop de fichiers" qui a du etre levée au moment de la tentative de creation)
- une fois le nom 8.3 ecrit, on va ajouter une entrée dans la FAT qui va contenir le nom long de la façon suivante :
"sigma"+les 62 premiers caracteres du nom+"1" pour arriver à 64 caractere, taille maxi d'une entree dans la FAT
- si le nom fait plus de 62, on ajoute JUSTE DERRIERE "sigma"+les 62 caracteres qui suivent+"2"
- etc... jusqu'a 255, taille maxi d'un nom de fichier long.
Les entrées commençant par "sigma" ne sont jamais affichées lors d'un parcours de repertoire pour les raisons historiques que j'ai données au début, donc la bidouille reste pseudo-invisible.
Les entrées "nom long" dans la FAT sont toujours immédiatement consecutives à l'entrée 8.3 (quand pour une raison X ou Y elles en sont séparées, seul le 8.3 est affiché, et les entrées longues deviennent invalides... Il y avait des utilitaires comme LFNBACKUP pour corriger ce genre de soucis ;))
Ca peut se voir en utilisant des vieux utilitaires disques qui datent du DOS : ils petent completement les plombs avec les noms longs :lol:
PS : les tailles max etc.. sont faites de memoire, peut etre qu'en FAT32 elles sont legerment differentes, mais c'est le principe de fonctionnement de la FAT ;)
(mode culture generale fini :D) |
