Pourquoi la limite de longueur de chemin d'accès de 260 caractères existe-t-elle dans Windows?

J'ai rencontré ce problème à quelques reprises à des moments inopportuns:

• Essayer de travailler sur des projets Java open source avec des chemins profonds
• Stockage d'arbres wiki Fitnesse profonds dans le contrôle de code source
• Une erreur lors de l'utilisation de Bazaar pour importer mon arborescence de contrôle de code source

Pourquoi cette limite existe-t-elle?

Pourquoi n'a-t-il pas encore été supprimé?

Comment gérez-vous la limite de chemin? Et non, passer à Linux ou Mac OS X n'est pas une réponse valable à cette question;)

Citant cet article https://docs.microsoft.com/en-us/windows/desktop/FileIO/naming-a-file#maximum-path-length-limitation

Limitation de longueur de trajet maximale

Dans l'API Windows (à quelques exceptions près décrites dans les paragraphes suivants), la longueur maximale d'un chemin est MAX_PATH , qui est définie sur 260 caractères. Un chemin local est structuré dans l'ordre suivant: lettre de lecteur, deux points, barre oblique inverse, composants de nom séparés par des barres obliques inverses et un caractère nul de fin. Par exemple, le chemin d'accès maximal sur le lecteur D est "D: \ une chaîne de chemin d'accès de 256 caractères <NUL>" où "<NUL>" représente le caractère nul de fin invisible pour la page de codes système actuelle. (Les caractères <> sont utilisés ici pour plus de clarté visuelle et ne peuvent pas faire partie d'une chaîne de chemin d'accès valide.)

Nous voyons maintenant qu'il s'agit de 1 + 2 + 256 + 1 ou [lecteur] [: \] [chemin] [null] = 260. On pourrait supposer que 256 est une longueur de chaîne fixe raisonnable à partir des jours DOS. Et pour en revenir aux API DOS, nous nous rendons compte que le système a suivi le chemin actuel par lecteur, et nous avons 26 lecteurs ( 32 avec symboles) maximum (et répertoires actuels).

L'INT 0x21 AH = 0x47 dit "Cette fonction renvoie la description du chemin sans la lettre de lecteur et la barre oblique inverse initiale." Nous voyons donc que le système stocke le CWD sous forme de paire (lecteur, chemin) et vous demandez le chemin en spécifiant le lecteur (1 = A, 2 = B,…), si vous spécifiez un 0, il suppose le chemin pour le lecteur renvoyé par INT 0x21 AH = 0x15 AL = 0x19. Alors maintenant, nous savons pourquoi il est 260 et non 256, car ces 4 octets ne sont pas stockés dans la chaîne de chemin d'accès.

Pourquoi une chaîne de chemin de 256 octets, car 640 Ko est suffisant de RAM.

Ce n'est pas strictement vrai car le système de fichiers NTFS prend en charge des chemins jusqu'à 32k caractères. Vous pouvez utiliser l 'api win32 et le \\?\préfixe " " du chemin pour utiliser plus de 260 caractères.

Une explication détaillée du long chemin du blog de l'équipe .Net BCL .
Un petit extrait met en évidence le problème des longs chemins

Une autre préoccupation est le comportement incohérent qui résulterait de l'exposition de la prise en charge du long chemin. Les chemins longs avec le \\?\préfixe peuvent être utilisés dans la plupart des API Windows liées aux fichiers, mais pas dans toutes les API Windows. Par exemple, LoadLibrary, qui mappe un module à l'adresse du processus appelant, échoue si le nom de fichier est plus long que MAX_PATH. Cela signifie donc que MoveFile vous permettra de déplacer une DLL vers un emplacement tel que son chemin d'accès dépasse 260 caractères, mais lorsque vous essayez de charger la DLL, elle échouera. Il existe des exemples similaires dans les API Windows; certaines solutions de contournement existent, mais elles sont au cas par cas.

La question est de savoir pourquoi la limitation existe toujours. Certes, les fenêtres modernes peuvent augmenter le côté MAX_PATHpour permettre des chemins plus longs. Pourquoi la limitation n'a-t-elle pas été supprimée?

• La raison pour laquelle il ne peut pas être supprimé est que Windows a promis qu'il ne changerait jamais.

Grâce au contrat d'API, Windows a garanti à toutes les applications que les API de fichier standard ne renverront jamais un chemin plus long que les 260caractères.

Considérez le code correct suivant:

WIN32_FIND_DATA findData;

FindFirstFile("C:\Contoso\*", ref findData);

Windows a garanti mon programme qu'il remplirait ma WIN32_FIND_DATAstructure:

WIN32_FIND_DATA {
   DWORD    dwFileAttributes;
   FILETIME ftCreationTime;
   FILETIME ftLastAccessTime;
   FILETIME ftLastWriteTime;
   //...
   TCHAR    cFileName[MAX_PATH];
   //..
}

Mon application n'a pas déclaré la valeur de la constante MAX_PATH, l'API Windows l'a fait. Mon application a utilisé cette valeur définie.

Ma structure est correctement définie et alloue uniquement des 592octets au total. Cela signifie que je ne peux recevoir qu'un nom de fichier inférieur à des 260caractères. Windows m'a promis que si j'écrivais correctement ma candidature, ma candidature continuerait de fonctionner à l'avenir.

Si Windows autorisait les noms de fichiers plus longtemps que les 260caractères, mon application existante (qui utilisait correctement l'API correcte) échouerait.

Pour quiconque appelle Microsoft à modifier la MAX_PATHconstante, il doit d'abord s'assurer qu'aucune application existante n'échoue. Par exemple, je possède toujours et j'utilise une application Windows écrite pour fonctionner sous Windows 3.11. Il fonctionne toujours sur Windows 10 64 bits. C'est ce que vous offre la compatibilité descendante.

Microsoft a créé un moyen d'utiliser les 32 768 noms de chemin complets; mais ils ont dû créer un nouveau contrat API pour le faire. D'une part, vous devez utiliser l' API Shell pour énumérer les fichiers (car tous les fichiers n'existent pas sur un disque dur ou un partage réseau).

Mais ils doivent également ne pas casser les applications utilisateur existantes. La grande majorité des applications n'utilisent pas l'API shell pour le travail sur fichier. Tout le monde appelle FindFirstFile/ FindNextFileet l'appelle un jour.

Depuis Windows 10. vous pouvez supprimer la limitation en modifiant une clé de registre.

Conseil À partir de Windows 10, version 1607, les limitations MAX_PATH ont été supprimées des fonctions de fichier et de répertoire Win32 courantes. Cependant, vous devez accepter le nouveau comportement.

Une clé de registre vous permet d'activer ou de désactiver le nouveau comportement de chemin long. Pour activer le comportement de chemin long, définissez la clé de registre sur HKLM\SYSTEM\CurrentControlSet\Control\FileSystem LongPathsEnabled(Type:) REG_DWORD. La valeur de la clé sera mise en cache par le système (par processus) après le premier appel à un fichier Win32 affecté ou à une fonction de répertoire (la liste suit). La clé de registre ne sera pas rechargée pendant la durée de vie du processus. Pour que toutes les applications du système reconnaissent la valeur de la clé, un redémarrage peut être nécessaire car certains processus peuvent avoir démarré avant la définition de la clé. La clé de registre peut également être contrôlée via la stratégie de groupe à l'adresse Computer Configuration > Administrative Templates > System > Filesystem > Enable NTFS long paths. Vous pouvez également activer le nouveau comportement de chemin long par application via le manifeste:

<application xmlns="urn:schemas-microsoft-com:asm.v3">
    <windowsSettings xmlns:ws2="http://schemas.microsoft.com/SMI/2016/WindowsSettings">
        <ws2:longPathAware>true</ws2:longPathAware>
    </windowsSettings>
</application>

Vous pouvez monter un dossier en tant que lecteur. À partir de la ligne de commande, si vous avez un chemin, C:\path\to\long\foldervous pouvez le mapper en lettre de lecteur en X:utilisant:

subst x: \path\to\long\folder

Une façon de faire face à la limite de chemin consiste à raccourcir les entrées de chemin avec des liens symboliques.

Par exemple:

1. créer un C:\prépertoire pour conserver des liens courts vers de longs chemins
2. mklink /J C:\p\foo C:\Some\Crazy\Long\Path\foo
3. ajouter C:\p\fooà votre chemin au lieu du long chemin

Vous pouvez activer des noms de chemin longs à l'aide de PowerShell:

Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\FileSystem' -Name LongPathsEnabled -Type DWord -Value 1 

Une autre version consiste à utiliser une stratégie de groupe dans Computer Configuration/ Administrative Templates/ System/ Filesystem:

Quant à savoir pourquoi cela existe toujours - MS ne considère pas cela comme une priorité et valorise la compatibilité ascendante par rapport à l'avancement de leur système d'exploitation (au moins dans ce cas).

Une solution de contournement que j'utilise consiste à utiliser les «noms courts» pour les répertoires du chemin, au lieu de leurs versions standard lisibles par l'homme. Donc, par exemple, pour C:\Program Files\que j'utilise, C:\PROGRA~1\ vous pouvez trouver les équivalents de noms courts en utilisant dir /x.

Quant à savoir comment gérer la limitation de la taille du chemin sous Windows - l'utilisation de 7zip pour emballer (et décompresser) vos fichiers sensibles à la longueur du chemin semble être une solution de contournement viable. Je l'ai utilisé pour transporter plusieurs installations IDE (ces chemins de plug-in Eclipse, yikes!) Et des tas de documentation générée automatiquement et je n'ai eu aucun problème jusqu'à présent.

Je ne sais pas vraiment comment il échappe à la limite de 260 caractères définie par Windows (à partir d'un PoV technique), mais bon, cela fonctionne!

Plus de détails sur leur page SourceForge ici :

"NTFS peut réellement prendre en charge des noms de chemin pouvant aller jusqu'à 32 000 caractères."

7-zip prend également en charge ces noms longs.

Mais il est désactivé dans le code SFX. Certains utilisateurs n'aiment pas les longs chemins, car ils ne comprennent pas comment travailler avec eux. C'est pourquoi je l'ai désactivé dans le code SFX.

et notes de version :

9.32 alpha 2013-12-01

• Prise en charge améliorée des noms de chemin de fichier de plus de 260 caractères.

4.44 beta 2007-01-20

• 7-Zip prend désormais en charge les chemins d'accès aux fichiers de plus de 260 caractères.

REMARQUE IMPORTANTE: pour que cela fonctionne correctement, vous devrez spécifier directement le chemin de destination dans la boîte de dialogue "Extraire" de 7zip , plutôt que de glisser-déposer les fichiers dans le dossier prévu. Sinon, le dossier "Temp" sera utilisé comme cache intermédiaire et vous rebondirez dans la même limitation de 260 caractères une fois que l'Explorateur Windows commencera à déplacer les fichiers vers leur "lieu de repos final". Voir les réponses à cette question pour plus d'informations.

C'est le cas, et c'est une valeur par défaut pour une raison quelconque, mais vous pouvez facilement la remplacer avec cette clé de registre:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem]
"LongPathsEnabled"=dword:00000001

Voir: https://blogs.msdn.microsoft.com/jeremykuhne/2016/07/30/net-4-6-2-and-long-paths-on-windows-10/

Une autre façon d'y faire face est d'utiliser Cygwin, selon ce que vous voulez faire avec les fichiers (c'est-à-dire si les commandes Cygwin répondent à vos besoins)

Par exemple, il permet de copier, déplacer ou renommer des fichiers que même l'explorateur Windows ne peut pas. Ou bien sûr en traiter le contenu comme md5sum, grep, gzip, etc.

Aussi pour les programmes que vous codez, vous pouvez les lier à la DLL Cygwin et cela leur permettrait d'utiliser de longs chemins (je n'ai pas testé cela cependant)