Nom de chemin court étrange sous Windows

Dans mon répertoire personnel sous Windows, j'ai beaucoup de dotfiles et dotfolders qui sont créés par un logiciel, et que je crée moi-même pour la cohérence. Je n'y ai jamais vraiment beaucoup réfléchi, sauf lorsque j'essaie de les créer dans l'interface de l'explorateur et qu'on me rappelle que je ne peux pas le faire, ce qui est agaçant, mais peu importe.

Je regardais mon PATH variable d’environnement et s’est rendu compte que l’un de ces dossiers avait été étrangement renommé lors de la conversion en nom abrégé Windows. La plupart dotfiles et dotfolders ressembler à ceci (nom long à droite, court à gauche):

CACHE~1    .cache
CPAN~1     .cpan
GOOGLE~1   .googlecl

etc.

Cependant, un dossier (mon go chemin du dossier) a été renommé comme ceci:

GO288D~1   .go

La seule chose que je peux comprendre, c’est que cela a quelque chose à voir avec le fait que ce soit un dotfolder prénom; Ç'est pourquoi? Qu'est-ce qui se passe réellement? Qu'est-ce que 288D signifie, et pourquoi Windows le place-t-il là?

windows command-line filenames

— dgo
source

Par chance, le go dossier de chemin contient un espace de fin? Si tel est le cas, un nom court / ancien sera toujours créé. Voici une bonne référence que j'ai trouvée très pratique: Comment Windows génère les noms de fichier 8.3 à partir de noms de fichier longs

— Run5k

Par défaut, la création du nom de fichier 8: 3 est activée mais peut être désactivée: support.microsoft.com/en-gb/help/121007/… Si vous créez, à titre d'exemple, un répertoire plus court, par exemple, mkdir .go , alors vous allez vous retrouver avec quelque chose comme: GO288D ~ 1, quand vous exécutez dir / X . Les caractères hexadécimaux à insérer dans le nom, c’est-à-dire 288D, en fonction de: en.wikipedia.org/wiki/8.3_nom_fichier sont dérivés d'un "hash non documenté du nom de fichier".

— HelpingHand

@EMK - Excellente référence, et je suis à peu près sûre que c'est la réponse, vous devriez donc envisager de soumettre votre commentaire en guise de réponse, en citant le paragraphe complet qui traite du "hash non documenté".

— AFH

Avec la création de nom de fichier 8: 3 activée ( peut être désactivé mais pas sans risque ), si vous créez, par exemple, un répertoire plus court que 8: 3, par exemple, par exemple.

mkdir .go

... alors vous vous retrouverez avec un nom de fichier 8: 3 de: GO288D ~ 1:

>dir /X | find ".go"
23/02/2017  16:48    <DIR>          GO288D~1     .go

Les caractères hexadécimaux supplémentaires servant à compléter le nom, c’est-à-dire 288D, selon: https://en.wikipedia.org/wiki/8.3_nom_fichier sont dérivés d'un "hash non documenté du nom de fichier"

À partir de Windows 2000, si au moins 4 fichiers ou dossiers sont déjà existent avec les mêmes 6 caractères initiaux dans leurs noms abrégés, LFN dépouillée est au contraire tronquée aux 2 premières lettres du basename (ou 1 si le nom de base n'a qu'une lettre), suivi de 4 chiffres hexadécimaux dérivés d'un hachage non documenté du nom de fichier, suivi d'un tilde, suivi d'un seul chiffre, suivi d'une période ., suivi des 3 premiers caractères de l'extension.

— HelpingHand
source

Pour en savoir plus, voici un article de blog qui analyse de manière inverse comment la fonction de hachage est générée, du moins sous Windows x64. tomgalvin.uk/blog/gen/2015/06/09/filenames

— Quackmatic