Pourquoi la limite de 260 caractères pour la longueur des chemins existe-t-elle dans Windows ?

Question

J'ai été confronté à ce problème à plusieurs reprises à des moments inopportuns :

• Essayer de travailler sur des projets Java open source avec des voies profondes
• Stockage des arbres wiki profonds de Fitnesse dans le contrôle de source
• Une erreur s'est produite lorsque j'ai essayé d'utiliser Bazaar pour importer mon arbre de contrôle des sources.

Pourquoi cette limite existe-t-elle ?

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

Comment faites-vous face à la limite des chemins d'accès ? Et non, passer à Linux ou Mac OS X n'est pas une réponse valable à cette question ;)

Answer 1

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

Limitation de la longueur maximale du chemin

Dans l'API Windows (avec quelques exceptions discutées dans les paragraphes suivants), la longueur maximum d'un chemin est de MAX_PATH qui est défini comme étant de 260 caractères. Un chemin d'accès local est structuré dans l'ordre suivant : lettre du lecteur, deux points, barre oblique inversée, composants du nom séparés par des barres obliques inversées et un caractère nul final. Par exemple, le chemin d'accès maximal sur le lecteur D est "D:\". un chemin d'accès de 256 caractères <NUL>" où "<NUL>" représente le caractère nul de terminaison invisible pour la page de code système actuelle. (Les caractères < > sont utilisés ici pour des raisons de clarté visuelle et ne peuvent pas faire partie d'une chaîne de chemin d'accès valide).

Nous voyons maintenant que c'est 1+2+256+1 ou [drive][:\][path][null] = 260. On peut supposer que 256 est une longueur de chaîne fixe raisonnable à l'époque du DOS. Et en revenant aux API DOS, nous nous rendons compte que le système suit le chemin actuel par lecteur, et nous avons 26 (32 avec les symboles) lecteurs maximum (et les répertoires actuels).

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

Pourquoi une chaîne de chemin de 256 octets, parce que 640K est une RAM suffisante.

Answer 2

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

Une explication détaillée du chemin long à partir de la base de données .Net. Blog de l'équipe du BCL .
Un petit extrait met en évidence le problème des chemins longs

Une autre préoccupation est le comportement incohérent qui résulterait de l'exposition du support des longs chemins. Les chemins longs avec l'option \\?\ peut être utilisé 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 du 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 compte plus de 260 caractères, mais lorsque vous essaierez de charger la DLL, il échouera. Il existe des exemples similaires dans l'ensemble des API de Windows ; il existe des solutions de contournement, mais au cas par cas.

Answer 3

Vous pouvez monter un dossier comme un lecteur. À partir de la ligne de commande, si vous avez un chemin d'accès C:\path\to\long\folder vous pouvez l'associer à une lettre de lecteur X: en utilisant :

subst x: \path\to\long\folder

Answer 4

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

Par exemple :

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

Answer 5

Nous venons de migrer vers TFS, et nous avons rencontré exactement le même problème. Dans notre cas, la profondeur de nos dossiers et leurs noms ne sont pas extrêmement profonds ou longs en soi. Cependant, lorsqu'ils sont associés à l'espace de noms complet généré en tant que noms de fichiers par la génération de code "Add Webservice reference" de Visual Studio, l'utilisation de TFS devient problématique.

Je viens de passer beaucoup de temps à préparer le passage de notre entreprise à TFS pour découvrir que nous obtenons cette erreur en essayant de créer des branches. Notre ancien système de contrôle de la source n'avait pas ce problème, et nous pourrions finir par devoir revenir en arrière.

Visual Studio génère lui-même ces fichiers de référence de services longs en fonction de l'espace de noms. Le système de fichiers sous-jacent prend en charge les noms plus longs. Avec des espaces de noms et des dossiers clairs, il est plus facile pour les personnes qui ne sont pas familiarisées avec la base de code de comprendre le cadre de votre produit. L'objectif du code généré automatiquement est d'économiser du temps et de l'argent. Nous ne pouvons pas nous permettre de parcourir une grande base de code en renommant tous les dossiers et fichiers en quelque chose de court et cryptique à chaque fois que nous rencontrons ce problème parce qu'un générateur de code nomme les fichiers comme ceci.

Le développement a évolué. Il faut en tenir compte. Jusqu'à ce qu'il le soit, c'est un énorme point négatif pour TFS, et cela lui a fait perdre ma recommandation par rapport à d'autres systèmes de contrôle de source (il y a même des systèmes gratuits qui n'ont pas cette limitation).