Hey How-To Geek!
So the other day, I was reorganizing some files on my computer, creating folders, that kind of stuff. Then, when I was moving some files into a folder, I get a message, stating that the resulting folder path would be too long. I was confused. I know that every single OS since DOS supports Long Filenames, yet Windows claims that the path is too long? Why does this happen?
Sincerly,
Mr. Disorganized
Le problème que vous rencontrez est une intersection malheureuse de deux systèmes qui, dans des cas comme celui-ci, génère une erreur. Pour comprendre exactement d'où vient l'erreur, nous devons explorer l'historique des noms de fichiers longs (LFN) et la manière dont Windows interagit avec eux avant de rechercher des solutions.
Les noms de fichiers longs ont été introduits dans l’architecture MS-DOS sous-jacente dans Windows 95. Le nouveau système LFN permettait des noms de fichier et de répertoire allant jusqu’à 255 caractères. Il s’agissait d’une extension bienvenue du système de noms de fichiers précédent, généralement appelée nom de fichier 8.3, car le nom était limité à huit caractères et à une extension à trois chiffres, également appelée nom de fichier court (SFN). Comme vous pouvez l’imaginer, à l’époque, il existait encore de nombreuses applications basées sur DOS et il n’y avait que quelques maux de tête pour tenter de faire en sorte que les nouveaux LFN et les anciens SFN se jouent bien. Si vous avez déjà rencontré une ancienne disquette ou un CD-ROM contenant des fichiers étrangement tronqués (comme abcdef ~ 1.txt), ce nom de fichier a été supprimé par certaines applications héritées utilisant SFN à partir de réseaux plus anciens et non pris en charge (comme abcdefghijk. SMS).
Cependant, nous sommes loin du milieu des années 90, et le problème du nom de fichier long est (pour la plupart) résolument résolu. Si vous utilisez une version de Windows des 10 dernières années, vous ne rencontrerez probablement jamais un conflit de longueur de nom de fichier comme celui que nous avions l'habitude de connaître sous DOS / Windows 95. Cela dit, nous rencontrons toujours des problèmes, comme vous l'avez découvert avec votre projet de nettoyage de disque. Mais pourquoi? Si le système de noms de fichiers longs de Windows prend en charge les dossiers et les noms de fichiers de 255 caractères maximum par composant, sur quel mur êtes-vous confronté? Nous ne pouvons pas reprocher à NTFS (le système de fichiers utilisé par la grande majorité des machines Windows modernes) car NTFS supportera un enchaînement de dossiers et de noms de fichiers d’une longueur maximale de 32 767 caractères. Cela dépasse de loin la structure de répertoires typique dont la plupart des utilisateurs auraient besoin.
Une restriction artificielle Windows se superpose au système LFN / NTFS: la variable MAX_PATH. La variable MAX_PATH indique qu’une structure de répertoires complète dans Windows ne peut pas contenir plus de 260 caractères, y compris la lettre du lecteur, les deux points, la barre oblique inversée et la barre oblique inversée nulle à la fin. Ainsi, vous ne disposez que d’un MAX_PATH réel potentiel de 256 caractères, par exemple. C: votre-chemin de 256 caractères.
Donc, ce qui s’est passé lorsque vous avez nettoyé votre ordinateur, c’est que vous aviez un répertoire avec un chemin déjà long (soit parce que les noms de dossiers étaient longs, les noms de fichiers étaient longs, ou les deux), ces répertoires dans un autre répertoire avec un chemin long, la longueur totale du nom du chemin dépasse la limite de 260 caractères imposée par la variable MAX_PATH.
Maintenant, vous pensez peut-être «Ah-hah! Nous allons simplement changer la variable MAX_PATH et résoudre le problème! »Hélas, ce n’est pas si simple. Non seulement la variable MAX_PATH est essentiellement codée de manière irréversible dans Windows, mais même si vous aviez eu la peine de la changer, vous auriez tellement mal à casser que cela n’en aurait pas valu la peine. Trop d'applications s'attendent à ce que la variable de chemin d'accès soit celle que Windows a depuis longtemps spécifiée. Nous ne pouvons tout simplement pas le changer sans créer un désordre énorme.
Où cela vous laisse-t-il? La solution la plus simple consiste simplement à éditer les données du chemin. Par exemple, si vous avez une tonne d'articles enregistrés pour lesquels l'application / l'extension que vous avez utilisée pour les enregistrer à partir du Web a créé un répertoire qui était le titre complet de l'article + l'article en tête, puis le nom du fichier lui-même est le titre complet de l'article + l'article lead, il serait très simple de frapper ou de dépasser MAX_PATH avec une seule sauvegarde. Editer ces énormes titres de dossiers et d’articles jusqu’à une taille plus raisonnable est un moyen simple de résoudre le problème.
Si vous avez un grand nombre de fichiers avec un long chemin et que vous ne voulez pas les éditer tous (ou si vous voulezeffacer une tonne d'anciens répertoires trop longs pour Windows à gérer lorsqu'ils sont restreints par la variable MAX_PATH), il existe un contournement en ligne de commande. Même si Windows est limité par la variable MAX_PATH, les ingénieurs Windows ont compris que les utilisateurs auraient parfois besoin de noms de chemin plus longs. En tant que tel, l'API Windows a une fonction permettant de gérer des chemins extrêmement longs.
Pour tirer parti de cette API et utiliser des outils de ligne de commande sur les noms de dossiers / fichiers difficiles à gérer, il vous suffit d'ajouter le nom du répertoire avec quelques caractères supplémentaires. Par exemple, si vous souhaitez supprimer une grande structure de répertoires (mais recevez une erreur en raison de la longueur du chemin lorsque vous l'avez tenté), vous pouvez modifier la commande à partir de:
rmdir c:documentssome-really-super-long-folder-name-scheme
à:
rmdir \?c:documentssome-really-super-long-folder-name-scheme
La clé est l'ajout de la
?
partie avant le début du chemin du fichier; Ceci indique à Windows de ne pas tenir compte des limitations imposées par la variable MAX_PATH et d'interagir avec le chemin que vous venez de fournir, tel que fourni / compris directement par le système de fichiers sous-jacent (qui peut clairement prendre en charge un chemin plus long).Comme toujours, faites preuve de prudence à l'invite de commande pour éviter de supprimer accidentellement les fichiers ou les répertoires que vous aviez l'intention de laisser intacts.
Si notre aperçu de ce problème vous a intéressé, n'hésitez pas à consulter cet article de la bibliothèque Réseaux de développeurs Microsoft, Nommer les fichiers, les chemins d'accès et les espaces de noms, pour plus d'informations sur ce qui se passe sous le capot.
Vous avez une question technique urgente? Envoyez-nous un email à [email protected] et nous ferons de notre mieux pour y répondre.
