Question Pourquoi n'est-il pas possible de nommer un dossier "._." Dans Windows 7?


Je viens de remarquer qu'il n'est pas possible de nommer un dossier ._. - ça s'appelle ._ au lieu. Parfois, il disparaît juste après l'avoir nommé mais réapparaît après avoir rafraîchi la vue. Windows semble avoir un problème avec les points à la fin d'un nom de fichier - pourquoi?


73
2018-01-18 20:57


origine


À noter est que vous êtes tombé sur le "hack" pour démarrer un nom de fichier avec un . sous Windows - jpmc26
@ThisNameBetterBeAvailable Non testé, mais cd -- -_- peut éventuellement travailler. le -- est un marqueur commun "fin des options". - TripeHound
@ThisNameBetterBeAvailable Non, -- par ses propres moyens "c'est la fin des options, traiter tout en commençant par - comme valeur littérale". Juste testé: mkdir -- -_- et cd -- -_- fonctionne comme je m'y attendais. - TripeHound
Alternativement, ./-_- devrait fonctionner aussi bien. - glglgl
@Alexander In linux, puisque cela semble être l'endroit où les commentaires sont allés, pour cd "-_-" le shell utilise les guillemets pour le regroupement mais ne les traite pas comme faisant partie de l'argument; il erreurs avec invalid option - Izkata


Réponses:


Windows exige normalement que les fichiers ne comportent aucune extension ou extension ayant au moins un caractère; il ne fait pas froid avec des extensions de longueur nulle, c’est-à-dire des noms de fichiers se terminant par .. Les dossiers peuvent aussi avoir des extensions. Par conséquent, Windows ne laisse pas leurs noms se terminer par un .. Source à partir de l'article lié à DavidPostill:

Utilisez un point pour séparer le nom du fichier de base de l’extension au nom d’un répertoire ou fichier.

(Soulignez le mien.) Si vous essayez de terminer un fichier ou un répertoire nommé avec un point, Windows suppose que vous ne vouliez aucune extension et que vous le supprimez, même si vous le créez avec md dans une invite de commande.

Zone dangereuse! Si vous voulez un nom de dossier se terminant par ., vous devrez utiliser la séquence de remplacement de nom brut de magie de \\?\. Dans une invite de commande, md \\?\C:\path\to\container\._. va en effet créer un dossier nommé ._., mais beaucoup de programmes auront des problèmes, même Explorer:

._. problems

Un tel répertoire ne peut être supprimé qu'avec rd suivi de son \\?\ nom ou renommé avec son court (8.3, dir /x) prénom.


123
2018-01-18 21:05



Merci pour votre réponse détaillée! :) Je pense que ce serait un dossier parfait pour cacher des choses secrètes comme les mots de passe à l'intérieur, car vous ne pouvez ouvrir le dossier que si vous le renommez en premier, et tout le monde ne sait pas comment le renommer. - Black
@EdwardBlack cela n'empêcherait pas quiconque pourrait lire les échanges de piles (et donc ne pourrait même pas assurer la sécurité contre le petit frère hypothétique). Le nom donné par dir /x le rend assez facile, et il y a d'autres fois ce nom est pratique. - Chris H
FWIW, les outils de ligne de commande de Cygwin peuvent également créer (et manipuler) de tels répertoires sur Windows 7, sans utiliser de séquence magique. - Steve Jessop
@EdwardBlack Comme Chris H l’a mentionné, ce n’est pas très secret, vous ne devriez donc rien stocker de particulièrement important dans un tel dossier. De plus, le secret et la protection numériques sont un problème qui a été résolu de nombreuses fois. Vous pouvez utiliser un nombre illimité de méthodes et de programmes de chiffrement pour assurer la sécurité des données sans avoir recours à des noms de dossiers obscurs. - Kris Harper
Nitpick: Au moins dans les 8,3 jours (je n'ai pas étudié ce qui est écrit sur le disque sur NTFS), la période n'a jamais été écrite sur le disque en premier lieu. Le nom a été divisé en nom et extension, ils ont été stockés séparément. A la lecture, il prit le nom et s’il y avait une extension, ajouta la période et l’extension du nom. Il n'y avait donc aucun moyen d'exprimer. dans la structure des répertoires, vous avez bien sûr perdu le point final. - Loren Pechtel


Windows semble avoir un problème avec les points à la fin d'un nom de fichier? Pourquoi est-ce?

Ne terminez pas un nom de fichier ou de répertoire avec un espace ou un point. Bien que le système de fichiers sous-jacent puisse prendre en charge de tels noms, le shell Windows et l'interface utilisateur ne le font pas.

Le lien source ci-dessous donne plus de détails sur les règles de nommage.

La source Nommer des fichiers, des chemins et des espaces de noms


22
2018-01-18 21:04



Cela me semble toujours bug. - ralu
@ralu Si c'est un bogue, alors MS semble totalement inintéressant à le corriger. Ces restrictions existent depuis Windows XP (sinon plus tôt). - DavidPostill♦
Windows XP? Je suppose que ces restrictions ont leurs racines dans MS-DOS 0.x - demandons à M. Gates de clarifier le problème ... - Christian Severin


Ce n'est pas un bug. Il est conçu pour éviter les problèmes de compatibilité.
C'est un résidu des anciens jours DOS.

Les systèmes de fichiers FAT12 (disquette) et FAT16 (FAT16 avant la prise en charge des noms de fichiers longs introduits dans Windows 95) ne contenaient que des noms de fichiers stockés dans 11 octets:
8 octets pour le nom, 3 pour l'extension. La "période" entre nom et extension n'a même pas été enregistrée. Il était implicite et ajouté automatiquement à des fins d'affichage.
Les répertoires n'avaient aucune extension. Au lieu de cela, les 3 octets de l'extension étaient remplis de caractères "$" (qui étaient illégaux dans les vrais noms).
Étant donné que Windows est toujours compatible avec cet explorateur et que de nombreux autres composants de Windows font en sorte que le point final disparaisse pour éviter de créer des problèmes de compatibilité.
Comme d'autres l'ont déclaré, vous pouvez gérer de tels dossiers en utilisant la sémantique RAW (\\? \ Prefix avant le nom de chemin absolu).
En coulisse NTFS et les systèmes de fichiers réseau ne rencontrent aucun problème avec de tels fichiers et dossiers. Il ne s’agit que d’un cas d’Explorateur essayant d’empêcher l’utilisateur de créer quelque chose qui pourrait causer des problèmes à d’autres logiciels.

(En fait, il y a aussi d'autres restes:
Les noms de fichiers tels que COM, COM1, COM2, AUX, PRN, LPT, LPT1, LPT2, LPT3, CON peuvent provoquer des problèmes similaires où Explorer et de nombreux composants Windows sont confus car ces noms sont des noms "réservés". l'ère DOS.)


17
2018-01-20 16:37



Pour tout autre lecteur qui était initialement incrédule en ce qui concerne le point non stocké: cela est correct pour CP / M et toutes les versions de FAT, y compris FAT16 et FAT32. - Ben N
Je me souviens de certains vieux programmes DOS (fonctionnant sous DOS, utilisant probablement directement les fonctions INT13), ce qui me donnait vraiment du chagrin en réussissant à créer un fichier nommé: foo.bar sur le lecteur c: ... - rackandboneman
@BenN: en fait, sur FAT32, c'est un peu différent; il stocke à la fois un nom de fichier court (8 + 3 octets avec des noms compatibles avec un "point implicite"), plus un nom de fichier long (souvent appelé LFN), composé de 255 caractères UCS-2 avec un point explicite, vous travaillez avec des applications 16 bits, vous travaillez toujours avec le LFN. - Matteo Italia
@MatteoItalia Je comprends que les noms de fichiers longs sont conservés dans des entrées de faux fichiers; Les installations Windows qui sont au courant recherchent ces entrées et les affichent à la place du SFN si possible. Voir Le post de Raymond Chen sur le sujet, ou la partie VFAT de la spécification de format FAT32 que j'ai liée ci-dessus. - Ben N
-1 vous vous trompez sur les extensions de répertoire; Peut-être que c'était vrai pour CP / M (ma mémoire est minable à propos de cet OS), mais j'utilise le répertoire "programm.ing" depuis mon arborescence depuis DOS, et je vois win.tue.nl/~aeb/linux/fs/fat/fat-1.html - Les entrées de répertoire sont traitées exactement comme des fichiers, elles peuvent également avoir un nom 8.3. Test: créer un répertoire 8.3 (mkdir testfile.name) et affiche son nom sous Windows (dir /x) - tu auras TESTFI~1.NAM, comme prévu. - vaxquis


Le problème ici est que Windows (DOS) a autorisé les noms de fichiers 8.3 sur les systèmes de fichiers FAT. Signification, 8 caractères, suivis par un. suivi de trois caractères. Unix et Linux autorisent n'importe quel caractère, sauf / et \ 0. \ 0 est le terminateur de chaîne de caractères C et / est le séparateur de répertoire. Tout le reste peut être utilisé.

Windows 95 a résolu ce problème en conservant une base de données de noms de fichiers courts (8.3) aux métadonnées LFN (Long File Names). Si vous avez effacé vos fichiers Windows 95 OS, vous devriez avoir des fichiers portant des noms étranges sur le disque lors de votre prochaine installation de Windows 95. Par exemple, "Mes documents" pourrait être nommé MYDOCU ~ 1 sur le disque. De toute évidence, si vous perdez les métadonnées, vous ne pourrez pas les convertir facilement.

Le shell doit faire face à de nombreux incréments d'historique qui traînent depuis les jours MS-DOS.

J'espère que cela t'aides


3
2018-01-20 20:06



Il n'y avait pas vraiment de base de données en soi; Windows a simplement coincé les parties du nom de fichier long sur le disque en tant que faux fichiers. Voir Le post de Raymond Chen sur le sujet. - Ben N