Pourquoi n'est-il pas possible de nommer un dossier «.

74

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

windows-7 windows

— Noir
source

21

Il est à noter que vous avez trébuché sur le "bidouillage" pour démarrer un nom de fichier avec .Windows.

— Jpmc26

8

@ThisNameBetterBeAvailable Non testé, mais cd -- -_-peut éventuellement fonctionner. Le --est un marqueur commun de "fin des options".

— TripeHound

13

@ThisNameBetterBeAvailable Non, --signifie en soi que " ceci est la fin des options, traite tout commençant par -comme une valeur littérale ". Juste testé: mkdir -- -_-et cd -- -_-fonctionne comme prévu.

— TripeHound

2

Sinon, ./-_-devrait fonctionner aussi bien.

— Glglgl

5

@Alexander Dans Linux, puisque cela semble être où les commentaires sont allés, car cd "-_-"le shell utilise les guillemets pour le regroupement mais ne les traite pas comme une partie de l'argument; il erreurs avecinvalid option

— Izkata

123

Windows requiert normalement que les fichiers n'aient pas d'extension ou une extension d'au moins un caractère; ce n'est pas cool avec des extensions de longueur nulle, c'est-à-dire des noms de fichiers qui finissent par .. Les dossiers peuvent aussi avoir des extensions, donc Windows ne laisse pas leurs noms se terminer par un .. Source, de l'article que DavidPostill a lié :

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

(J'insiste particulièrement sur moi.) Si vous essayez de terminer un fichier ou un répertoire portant un point, Windows suppose simplement que vous ne voulez pas d'extension et le supprime donc, même si vous le créez avec mdune invite de commande.

Zone dangereuse! Si vous voulez vraiment que le nom d'un dossier se termine ., vous devez utiliser la séquence de remplacement du nom brut brut \\?\. Dans une invite de commande, vous md \\?\C:\path\to\container\._.créerez effectivement un dossier nommé ._., mais beaucoup de programmes auront des problèmes avec cela, même Explorer:

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

— Ben N
source

1

Merci pour votre réponse détaillée! :) Je pense que ce serait un dossier parfait pour cacher des informations secrètes telles que des mots de passe, car vous ne pouvez ouvrir le dossier que si vous le renommez d'abord, et tout le monde ne sait pas comment le renommer.

— Noir

19

@ EdwardBlack, cela n'arrêterait personne qui pourrait lire l'échange de pile (et ne fournirait donc même pas de sécurité contre l'hypothétique petit frère). Le nom donné par le dir /xrend assez facile, et il y a d'autres fois, ce nom est pratique.

— Chris H

11

FWIW, les outils de ligne de commande de Cygwin peuvent également créer (et manipuler) de tels répertoires sous Windows 7, sans utiliser de séquence magique.

— Steve Jessop

4

@ EdwardBlack Comme Chris H l'a mentionné, ce n'est pas très secret, vous ne devez donc rien stocker de particulièrement important dans un tel dossier. De plus, le secret numérique et la protection sont des problèmes qui ont été résolus à maintes reprises. Vous pouvez utiliser un nombre illimité de méthodes et de programmes de chiffrement pour protéger vos documents sans vous fier à des noms de dossiers obscurs.

— Kris Harper

3

Nitpick: Au moins dans les 8.3 jours (je n'ai pas cherché à savoir ce qui était écrit sur le disque sous NTFS), la période n'avait jamais été écrite sur le disque. Le nom a été divisé en nom et extension, ils ont été stockés séparément. En le lisant, il a pris le nom et, s'il y avait une extension, ajouté la période et l'extension au nom. Ainsi, il n'existait aucun moyen d'exprimer ._. dans la structure de répertoires, vous avez bien sûr perdu le dernier point.

— Loren Pechtel

22

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 par 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.

Fichiers de dénomination source , chemins d'accès et espaces de noms

— DavidPostill
source

5

Cela sonne toujours comme un bug pour moi.

— ralu

@ralu S'il s'agit d'un bogue, MS semble totalement inintéressant à le résoudre. 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 la question ...

— Christian Severin

17

Ce n'est pas un bug. Il est conçu pour éviter les problèmes de compatibilité.
C'est un reste de l'ancien DOS.

Les systèmes de fichiers FAT12 (disquette) et FAT16 (FAT16 antérieur à la prise en charge des noms de fichiers longs introduits dans Windows 95) ne disposaient que de noms de fichiers stockés sur 11 octets:
8 octets pour le nom et 3 pour l'extension. La "période" entre le nom et l'extension n'était même pas stockée. C'était implicite et ajouté automatiquement à des fins d'affichage.
Les répertoires n'ont pas du tout d'extensions. Au lieu de cela, les 3 octets de l'extension étaient remplis de caractères "$" (qui étaient illégaux dans de vrais noms).
Étant donné que Windows est toujours compatible avec cet explorateur et de nombreux autres composants de Windows, la période de fin disparaît en mode silencieux afin d'éviter de créer des problèmes de compatibilité.
Comme d'autres l'ont déjà dit, vous pouvez réellement gérer de tels dossiers en utilisant la sémantique RAW (le préfixe \\? \ Avant le nom de chemin absolu).
En coulisse, NTFS et les systèmes de fichiers en réseau ne rencontrent aucun problème avec de tels fichiers et dossiers. Il s’agit simplement d’explorateur qui essaie d’empêcher l’utilisateur de créer quelque chose qui pourrait causer des problèmes à d’autres logiciels.

(En fait, il reste également quelques restes:
des noms de fichiers tels que COM, COM1, COM2, AUX, PRN, LPT, LPT1, LPT2, LPT3, CON peuvent également causer des problèmes similaires, où Explorer et de nombreuses autres parties de Windows sont confondus. parce que ces noms sont des noms "réservés" qui datent également de l’ère DOS.)

— Tonny
source

3

À tous les autres lecteurs qui étaient initialement incrédules en ce qui concerne le point non stocké: c'est exact pour CP / M et toutes les versions de FAT, y compris FAT16 et FAT32 .

— Ben N

1

Je me souviens d'un vieux programme DOS (fonctionnant sous DOS, utilisant probablement directement les fonctions INT13) qui me causait un véritable chagrin une fois en réussissant à créer un fichier nommé a: foo.bar sur le lecteur c: ...

— rackandboneman

2

@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 rétrocompatibles "à point implicite"), ainsi qu'un nom de fichier long (souvent appelé LFN), composé de 255 caractères UCS-2 au maximum avec un point explicite, et vous travaillez avec des applications 16 bits, vous travaillez toujours avec le réseau LFN.

— Matteo Italia

1

@MatteoItalia Je crois comprendre que les noms de fichier longs sont conservés dans des entrées de fichier factices; Les installations Windows connues sont à la recherche de ces entrées et les rendent si possible à la place du SFN. Voir l'article 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

-1 vous vous trompez sur les extensions de répertoire; c’était peut-être vrai pour CP / M (ma mémoire est folle à propos de ce système d’exploitation), mais j’utilise le répertoire "programm.ing" de mon arbre depuis le temps 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 aussi avoir un nom 8.3. Test: créez un répertoire 8.3 ( mkdir testfile.name) et affichez son nom DOS sous Windows ( dir /x) - vous obtiendrez TESTFI~1.NAMcomme prévu.

— vaxquis

3

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 de a. suivi de trois personnages. Unix et Linux autorisent tous les caractères, à l'exception de / et \ 0. \ 0 est le terminateur de la chaîne de caractères C et / le séparateur de répertoire. Tout le reste peut être utilisé.

Windows 95 contournait ce problème en conservant une base de données contenant des noms de fichiers courts (8.3) en méta-données LFN (Long File Names). Si vous supprimiez vos fichiers du système d'exploitation Windows 95, il ne resterait plus que des fichiers portant des noms étranges sur le disque lors de votre prochaine installation de Windows 95. Par exemple, "Mes documents" pourrait s'appeler MYDOCU ~ 1 sur le disque. Évidemment, si vous perdez les métadonnées, vous ne pourrez pas les convertir facilement.

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

J'espère que cela t'aides

— Ed Neville
source

1

Il n'y avait pas vraiment de base de données en soi; Windows a simplement bloqué les parties du nom de fichier long sur le disque sous forme de faux fichiers. Voir l'article de Raymond Chen sur le sujet .

— Ben N

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

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