Alors que NTFS autorise des chemins de 32 000 caractères, vous avez trouvé la limitation de longueur de chemin de 259 caractères de l'API Win32 .
Dans l'API Windows (à quelques exceptions près abordées dans le [document lié]), la longueur maximale d'un chemin MAX_PATHest définie sur 260 caractères.
(Il y a en plus un NULLcaractère de terminaison ajouté au chemin, nous donnant 259 caractères utilisables.)
Étant donné qu'Explorer (et presque toutes les autres applications Windows) s'appuient sur l'API Win32 pour l'accès au système de fichiers, il n'est pas pratique de contourner cette limitation même si c'est possible :
L'API Windows possède de nombreuses fonctions qui ont également des versions Unicode pour autoriser un chemin de longueur étendue pour une longueur de chemin totale maximale de 32 767 caractères. Ce type de chemin est composé de composants séparés par des barres obliques inverses, chacun jusqu'à la valeur renvoyée dans le lpMaximumComponentLengthparamètre de la GetVolumeInformationfonction (cette valeur est généralement 255 caractères). Pour spécifier un chemin de longueur étendue, utilisez le préfixe "\\? \". Par exemple, "\\? \ D: \ très long chemin ".
Malheureusement, vous ne pouvez pas simplement taper \\?\D:\very long pathdans une fenêtre Explorer. L'application doit être conçue pour tirer parti de ces API et gérer des noms de chemin très longs.
Une façon d'accéder à des chemins de longue durée sous Windows consiste à installer Cygwin , une couche d'émulation * nix pour Windows. Dans mes tests, Cygwin ne semble pas être limité par MAX_PATH; bash et vi n'ont eu aucun problème avec les chemins de 2 000 caractères.
Gardez à l'esprit que même si vous pouvez utiliser bash pour parcourir des chemins de longue durée, vous ne pourrez probablement pas ouvrir de fichiers dans ces chemins dans les applications Windows normales. Par exemple, en tapant notepadalors que le répertoire de travail est un chemin de longueur étendue, vous obtenez
Erreur: le répertoire de travail actuel a un chemin d'accès plus long que celui autorisé pour un répertoire de travail Win32. Impossible de démarrer l'application Windows native à partir d'ici.
Et essayer notepad "\\?\D:\very long path\file.txt"ne fonctionne pas non plus; il se lance, mais dit simplement "Impossible de trouver le fichier ..." Essayer la même chose avec Notepad ++ le plante. (Probablement un débordement de tampon.)
Votre autre option pour accéder à des fichiers spécifiques enfouis profondément dans un chemin de longue durée consiste à raccourcir le chemin lui-même en créant un point de jonction NTFS . À partir d'une invite de commande élevée:
D:\> mklink /J jct "\\?\D:\very\long\path"
Vous pouvez maintenant accéder au contenu de à D:\very\long\path\partir de D:\jct\. Vous ne rencontrerez aucun problème de longueur de chemin, car pour l'explorateur et les autres applications, le chemin est juste D:\jct\(ou autre). Le pilote NTFS gère la redirection du chemin (le «point d'analyse») de manière transparente.
L'inconvénient de cette approche est évidemment que vous devez créer une jonction près du fichier auquel vous souhaitez accéder; vous ne pouvez toujours pas simplement parcourir toute la structure du répertoire.
En ce qui concerne les caractères spéciaux ( " * : < > ? \ |), c'est tout simplement un non-go. Ces caractères ont des significations spéciales dans Windows, il n'est donc pas possible de les utiliser dans des chemins. (Cygwin vous permet de créer des fichiers avec des caractères spéciaux, mais il le fait en remplaçant les caractères par des caractères Unicode spéciaux, qu'il remplace ensuite lors de la lecture. La visualisation de ces fichiers créés par Cygwin sous Linux ou dans l'Explorateur ne serait pas correcte, car les caractères Unicode ne seraient pas substitués en arrière.)
Cela dit, que faites-vous qui nécessite de très longs chemins? Peut-être pourriez-vous vous faciliter la vie en réévaluant ce que vous faites et en évitant les longs chemins. Il y a de fortes chances que vous n'ayez pas besoin de chemins aussi longs de toute façon .
