Quel est le comportement attendu par défaut lorsque Windows rencontre deux fichiers portant le même nom mais des majuscules différentes dans une partition NTFS?

Il est facile d'écrire deux fichiers sur une partition NTFS à partir de Linux, et d'avoir ces deux fichiers contiennent les mêmes lettres mais avec une casse différente, par exemple some_file.txt et Some_File.txt. Linux les distingue.

Comment Windows les gère-t-il?

windows filesystems

— trusktr
source

Personnellement, en raison de tous les facteurs impliqués, je dirais simplement que cela provoque un comportement indéfini. Si Windows ne définit pas le comportement dans ce cas, alors par définition, il n'est pas défini. Si Windows ne définit le comportement, je traiterais toujours comme un comportement non défini, parce que je doute sérieusement que tous les programmes traitent cette manière cohérente.

— jpfx1342

Les personnalités MS-DOS, WOW et Win32 renverront le premier fichier correspondant. Pour certaines applications et API, l' insensibilité à la casse est appliquée (par exemple, MS-DOS ne peut tout simplement pas y faire face). La personnalité POSIX se différenciera et est sensible à la casse par défaut (si vous avez installé les outils UNIX, par exemple). L'invite de commande native de Windows NT affichera les deux mais, selon les paramètres (ObCaseInsensitive) et les API que les outils utilisent, accéder uniquement à la première qu'il trouve.

Voir l'article Microsoft Technet Les noms de fichiers sont sensibles à la casse sur les volumes NTFS (KB100625) et également une discussion détaillée des subtilités de la casse dans les différents sous-systèmes NT: Comprendre la casse dans Windows: obcaseinsensitive, FILE_CASE_SENSITIVE_SEARCH

En particulier, la valeur ObCaseInsensitive contrôle la sensibilité à la casse de l'ensemble du gestionnaire d'objets NT:

HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\kernel\ dword:ObCaseInsensitive

Lorsqu'il est défini sur 0, le gestionnaire d'objets s'exécute en mode sensible à la casse.

Lorsqu'il est défini sur 1, le gestionnaire d'objets s'exécute en mode insensible à la casse.

Lorsqu'elle n'est pas spécifiée, NT 5.1 (Windows XP) et les éditions ultérieures fonctionnent par défaut en mode insensible à la casse.

obcaseinsensitive n'a aucune signification dans NT 5.0 (Windows 2000) et les versions antérieures de NT, qui s'exécutent toujours en mode sensible à la casse.

Cygwin devrait ramasser les paramètres de sensibilité à la casse sous-jacents / effectifs à ce stade.

La question SuperUser connexe Comment configurer la sensibilité à la casse des noms de dossier dans Windows 7? et l'article TechNet Configurer la sensibilité à la casse pour les noms de fichiers et de dossiers contiennent plus d'informations sur l'activation de la sensibilité à la casse complète pour les fichiers et les dossiers dans NT si vous devez gérer cette situation régulièrement.

Ressources supplémentaires sur les outils sensibles à la casse / accès aux volumes NTFS / NFS:

— Maxx Daymon
source

S'il existe deux fichiers, One.txt et ONE.txt, quel fichier "correspondra en premier" si je fournis one.txt? Existe-t-il des règles sur lequel sera le "premier fichier correspondant"?

— trusktr

Il est probablement basé sur l'ordre des fichiers internes dans un répertoire. Je vais l'essayer demain, si tu veux savoir exactement.

— Daniel B

Le premier est uniquement déterminé par l'ordre dans lequel ils apparaissent dans le répertoire. Ce n'est PAS nécessairement l'ordre dans lequel ils sont créés. Et cela peut changer si l'un des fichiers est modifié ou si le directoy est mis à jour. (Chkdsk, Defrag, supprimer, copier et déplacer d'autres fichiers dans ce dossier peuvent tous changer l'ordre.)

— Tonny

@trusktr Eh bien, apparemment, il y a une sorte d'ordre, après tout. J'ai créé plusieurs ensembles de fichiers (en utilisant NTFS-3G), chacun avec une capitalisation différente et dans des ordres différents. Windows (ou, plus précisément, le Bloc-notes) sélectionne toujours le fichier en commençant par une lettre majuscule, quel que soit l'ordre de création. morerenvoie juste un point d'interrogation, cependant.

— Daniel B

@trusktr Il suivra l'ordre des entrées INDX de l'arborescence B + du répertoire. Cet arbre est conservé trié par conception, mais peut varier légèrement en fonction du pilote NTFS. Ce sera (OnCaseInsensitive = 0, API Win32 / DOS / WOW) la première correspondance lors de la marche dans l'arborescence (triée) du nom spécifié et du nom de l'entrée INDX. NTFS utilise des comparaisons ordinales, donc les majuscules doivent toujours être trouvées avant les minuscules. (AZ = 0041-005A, az = 0061-007A)

— Maxx Daymon

Ce n'est pas le cas. Il considère les différences de casse, mais sinon les mêmes noms exacts sont le même fichier.

Vous pouvez tester cela en créant un fichier en minuscules, puis en créer un autre avec une seule lettre en haut et il se plaindra.

— Casey
source

Je n'ai pas l'environnement pour tester cela en ce moment. Je n'ai que OS X pour le moment. Pourriez-vous décrire ce qui se passe? Ma première supposition serait que Windows sélectionne (peut-être par inadvertance) le fichier à lire / écrire selon certains critères (par exemple, l'ordre lexical avec les minuscules ayant priorité, ou vice versa). Ou ne permet-il aucunement de manipuler un fichier?

— trusktr

@trusktr Le système se plaint que le fichier existe déjà, selon l'application ou le code impliqué, il sera ignoré en silence et remplacera simplement le fichier préexistant. Comme l'a commenté jpfx1342 , ce problème doit être traité comme un comportement non défini.

— Casey