Bien que NTFS autorise des chemins d’environ 32 000 caractères, vous avez découvert la limitation de longueur de chemin de 259 caractères de l’API Win32.
Dans l’API Windows (avec certaines exceptions discutées dans le [document lié]), la longueur maximale d’un chemin est MAX_PATH, qui est défini comme 260 caractères.
(Il y a en plus un caractère de terminaison NULL ajouté au chemin, ce qui nous donne 259 caractères utilisables.)
Parce que l’Explorateur (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 dispose de nombreuses fonctions qui ont aussi des versions Unicode permettant un chemin de longueur étendue pour une longueur totale maximale de 32 767 caractères. Ce type de chemin est composé de composants séparés par des barres obliques inverses, chacun pouvant avoir jusqu’à la valeur retournée dans le paramètre lpMaximumComponentLength de la fonction GetVolumeInformation (cette valeur est communément de 255 caractères). Pour spécifier un chemin de longueur étendue, utilisez le préfixe « \?\ ». Par exemple, « \?\D:\very long path ».
Malheureusement, vous ne pouvez pas simplement taper \\?\D:\very long path dans une fenêtre de l’Explorateur. L’application doit être conçue pour tirer parti de ces API et gérer les noms de chemins très longs.
Un moyen d’accéder aux chemins de longueur étendue sous Windows est d’installer Cygwin, une couche d’émulation *nix pour Windows. Lors de mes tests, Cygwin ne semble pas être limité par MAX_PATH ; bash et vi n’ont eu aucun problème avec des chemins de 2 000 caractères.
Gardez à l’esprit que même si vous pouvez utiliser bash pour parcourir les chemins de longueur étendue, vous ne pourrez probablement pas ouvrir les fichiers dans ces chemins dans les applications Windows classiques. Par exemple, taper notepad alors que le répertoire de travail est un chemin de longueur étendue vous donne
Error: Current working directory has a path longer than allowed for a Win32 working directory. Can’t start native Windows application from here.
Et essayer notepad "\\?\D:\very long path\file.txt" ne fonctionne pas non plus ; il se lance, mais dit simplement
« Can’t find file … ». Essayer la même chose avec Notepad++ le fait planter. (Probablement un dépassement de tampon.)
Votre autre option pour accéder à des fichiers spécifiques enfouis profondément dans un chemin de longueur étendue est de raccourcir le chemin lui-même en créant un point de jonction NTFS. Depuis une invite de commandes élevée :
D:\> mklink /J jct "\\?\D:\very\long\path"
Vous pouvez maintenant accéder au contenu de D:\very\long\path\ depuis D:\jct\. Vous ne rencontrerez aucun problème de longueur de chemin car, du point de vue de l’Explorateur et des autres applications, le chemin est simplement D:\jct\ (ou autre). Le pilote NTFS gère la redirection du chemin (le « point de ré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 voulez accéder ; vous ne pouvez toujours pas simplement parcourir l’ensemble de la structure de répertoires.
Concernant les caractères spéciaux (" * : < > ? \ |), c’est tout simplement impossible. Ces caractères ont des significations spéciales dans Windows, il n’est donc pas possible de les utiliser dans les chemins. (Cygwin vous permet de créer des fichiers avec des caractères spéciaux, mais il le fait en substituant les caractères par des caractères Unicode spéciaux, qu’il substitue ensuite en retour à la lecture. Visualiser ces fichiers créés par Cygwin sous Linux ou dans l’Explorateur n’aurait pas l’air correct, puisque les caractères Unicode ne seraient pas re-substitués.)
Cela étant dit, que faites-vous qui nécessite des chemins très longs ? Vous pourriez peut-être vous simplifier la vie en réévaluant ce que vous faites et en évitant les chemins longs. Il y a des chances que vous n’ayez pas besoin de chemins aussi longs de toute façon.