Developpez.com

Une très vaste base de connaissances en informatique avec
plus de 100 FAQ et 10 000 réponses à vos questions

Windows 10 : Microsoft met silencieusement fin à la limitation à 260 caractères pour les chemins d'accès
Dans la Build 14352 en préversion

Le , par Stéphane le calme, Chroniqueur Actualités
Les noms de fichiers Windows étaient autrefois limités à un format 8x.3x : le nom du fichier ne prenait alors que huit caractères et l’extension trois. Puis vint Windows 95 et une extension de ces limites. Il faut noter que le système de fichiers de Windows continue d’imposer certaines restrictions comme le nombre de caractères qui peuvent être utilisés pour les noms de fichiers ou le nombre de caractères pour les chemins d’accès. Si pour cette dernière elle était fixée à 260 caractères, la dernière préversion de Windows 10, la Build 14352, va venir briser cette limite. Une limite imposée par les applications utilisant l’API Win32, afin d’éviter des dépassements de tampon lors de l’utilisation d’un chemin d’accès, mais qui peut s’avérer très vite problématique pour des fichiers qui se situent loin dans l’arborescence de Windows.

Si Microsoft l’a passé sous silence lors de la présentation de la Build 14352, cette limite devrait passer à celle imposée par le NTFS lui-même, c’est-à-dire 32 767 caractères. La description de cette fonctionnalité est disponible dans l’éditeur de caractères : « l’activation des chemins d’accès longs de NTFS permettra aux manifestes d’applications Win32 et d’applications Windows Store d’accéder à des chemins au-delà de la limite normale de 260 caractères par nœud ».

Il faut noter que cette fonctionnalité n’est pas activée par défaut et qu’il faut le faire manuellement. Il suffit de se rendre dans l’éditeur de stratégie de groupe locale en cliquant sur le menu Démarrer puis en tapant l’entrée « gpedit.msc ». Il faudra alors se rendre à Stratégie Ordinateur local > Configuration ordinateur > Modèles d’administration > Système > Systèmes de fichiers > NTFS. Une fois à ce niveau, vous verrez une option vous permettant alors d’activer les chemins d’accès longs.


Si vous vous servez d’une version de Windows qui ne fournit pas un accès à l’éditeur de stratégie de groupe locale (Windows 10 en édition non professionnelle), il faudra passer par l’éditeur du registre. Cliquez sur le menu Démarrer, tapez « regedit.exe » et suivez ce chemin d’accès : HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Group Policy Objects\{48981759-12F2-42A6-A048-028B3973495F}Machine\System\CurrentControlSet\Policies

Une fois rendus à ce chemin, cherchez l’entrée « LongPathsEnabled ». Si elle n’existe pas, effectuez un clic droit, sélectionnez New DWORD (32-bit), renommez-le « LongPathsEnabled » (sans les guillemets), entrez la valeur 1 et le tour sera joué.

Comme vous pouvez le constater, ce changement apporté par Microsoft concerne non seulement les logiciels Win32, mais aussi les applications de son Windows Store, étant donné le rôle essentiel qu’elles jouent pour l’avenir de Windows. Dans le manifeste d’application, qui contient les informations liées à une application (telles que le nom, l'auteur, l'icône) dans un document qui peut être utilisé par les utilisateurs et les marchés d'applications, il faut se rassurer que les applications ajoutent une mention de cette nouvelle police afin de vérifier qu’elles prennent bien en charge les chemins d’accès allant au-delà des traditionnels 260 caractères.

Ce qui signifie que, à moins que cela ne soit spécifié, ce changement ne sera pas pris en compte. Les développeurs doivent donc mettre leurs applications à jour pour pouvoir bénéficier de cette fonctionnalité.

La fonction, qui est actuellement disponible sur la Build actuelle de la préversion de Windows 10, devrait être disponible sur tous les systèmes avec le lancement de la Windows 10 Anniversary Update (au nom de code Redstone) prévu pour cet été.

Source : blog Windows (disponibilité de la Build 14352), GHacks

Et vous ?

Qu'en pensez-vous ?


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de araqiel araqiel - Nouveau membre du Club https://www.developpez.com
le 31/05/2016 à 19:23
Enfin nous pourrons mettre nos projets Xamarin dans le dossier de Visual Studio et plus dans un dossier à nom court à la racine du disque.
C'était vraiment pénible cette limitation.
Avatar de RyzenOC RyzenOC - Membre émérite https://www.developpez.com
le 31/05/2016 à 19:38
L'activation de cette fonctionnalité peut elle entraîné des risques incompatibilité ?

si j'ai des vielles applications win32, (mais qui ont un chemin d’accès <260 caractères) vont elle continuer à fonctionner normalement ?
Et si inversement sa dépasse les 260 caractères que se passe t'il ?
Avatar de chrtophe chrtophe - Rédacteur/Modérateur https://www.developpez.com
le 31/05/2016 à 20:17
L'activation de cette fonctionnalité peut elle entraîné des risques incompatibilité ?

Je dirais déjà oui dans le cadre d'un réseau hétérogène ou tous les postes ne sont pas en Windows 10.
Avatar de RyzenOC RyzenOC - Membre émérite https://www.developpez.com
le 31/05/2016 à 20:24
Je dirais déjà oui dans le cadre d'un réseau hétérogène ou tous les postes ne sont pas en Windows 10.

Heureusement il reste encore 1 mois pour la mise a jour gratuite
Sinon c'est toujours sympa de voir NTFS continuer d'évoluer, même après 20ans d'existence, mais j'imagine pas le bordel que sa être le code source du bousin, avec tous les patchs et surcouche rajouté au fils dans ans.

Mais j'aimerais bien que windows puisse lire et écrire nativement sur du ext3-4, ils arrivent à mettre un shell linux dans l'os, mais pas à lire une partition ext3 ?!
Avatar de jrh09350 jrh09350 - Nouveau Candidat au Club https://www.developpez.com
le 31/05/2016 à 23:19
la rubrique que vous indiquez n'existe pas

Windows 10 Insider 1511 build 14352.1002
Avatar de Chauve souris Chauve souris - Membre chevronné https://www.developpez.com
le 31/05/2016 à 23:52
Effectivement je bute souvent sur cette limitation avec des noms longs dans des arborescences à 6-10 niveaux. En particulier en programmation qui ne dépend pas complètement de moi à ce niveau.

Donc c'est une bonne chose et ma question sera : y aura-t-il un patch pour utiliser les noms (très) long sur Windows 7 et 8.1 (sans oublier les serveurs) ? On parle des versions 64 bits, bien sûr.
Avatar de gretro gretro - Membre actif https://www.developpez.com
le 01/06/2016 à 4:43
Wow! Il était quand même temps, en 2016, de retirer cette limitation stupide. Combien de fois je me suis tapé des erreurs Powershell et autres avec ça, surtout avec des node_modules et des paths Sitecore.

En espérant vivement que ce patch fasse son chemin jusqu'aux anciennes versions de Windows (7, 8 et équivalents serveur).
Avatar de thewyx thewyx - Membre à l'essai https://www.developpez.com
le 01/06/2016 à 8:55
Pour la petite histoire, du temps du 8+3 le nombre d'entrées par dossier était limité. Le passage à Win95 et les noms longs, s'est fait en utilisant un bug de la FAT : quand tous les attributs d'un fichier sont à vrai (caché, protégé en écriture, archive etc.) il devient totalement non listable. D'où l'idée d'utiliser ça pour Win95 : on découpe un nom long en paquets de 8+3. Avec la limitation du nombre d'entrée, on pouvait se voir interdire la création d'un fichier purement et simplement, surtout à la racine d'un disque. Et toutes les anciennes appli ne pouvaient pas voir les noms longs et listaient la la racine du fichier en 8+3.
Là il faut craindre la même chose. Microsoft a fait vivre un gros paradoxe : NTFS supporte 32769 de long, mais l'OS au dessus ne gère que des noms de 260 chemin compris ! Même si Windows 10 se met à le gérer quid des appli qui sont câblées en 260 ???? Quid des API ????
Comme beaucoup de monde je suppose, j'ai déjà été confronté au problème des "faux noms longs" de Windows, et même pire, la création par d'autres OS de fichiers qu'on ne pouvait ni renommer, ni déplacer, ni supprimer parce que trop long.
Bref, ça finira par arriver, mais ça prendra encore du temps...
Avatar de Zefling Zefling - Membre émérite https://www.developpez.com
le 01/06/2016 à 9:00
Citation Envoyé par sazearte  Voir le message
Sinon c'est toujours sympa de voir NTFS continuer d'évoluer, même après 20ans d'existence, mais j'imagine pas le bordel que sa être le code source du bousin, avec tous les patchs et surcouche rajouté au fils dans ans.

En fait, ce n’est pas NTFS qui a évolué, il a toujours parmi un chemin de 32k¹, c'est d'ailleurs bien ça le problème vu qu'on pouvait créer un chemin aussi long, mais l'OS lui était pas foutu d'y accéder. Là, c'est juste que Windows support correctement son propre système de fichiers, ce que je trouve hallucinant.

Édit : d'ailleurs je noterais que NTFS supporte les liens symboliques, mais que ça n'a jamais vraiment été mise en place.

¹ 32,767 Unicode characters with each path component (directory or filename) up to 255 characters long
Avatar de Chauve souris Chauve souris - Membre chevronné https://www.developpez.com
le 01/06/2016 à 14:12
Citation Envoyé par Zefling  Voir le message
Édit : d'ailleurs je noterais que NTFS supporte les liens symboliques, mais que ça n'a jamais vraiment été mise en place.

A ce sujet il y a un petit utilitaire de Russinovitch (si je ne massacre pas son nom) "junction", bien pratique à utiliser dans un serveur FTP, par exemple.
Offres d'emploi IT
Data scientist senior H/F
Safran - Ile de France - Magny-les-Hameaux (Saclay)
Responsable protection des données H/F
Safran - Ile de France - Magny-les-Hameaux (78114)
Architecte et intégrateur scade/simulink H/F
Safran - Ile de France - Vélizy-Villacoublay (78140)

Voir plus d'offres Voir la carte des offres IT
Contacter le responsable de la rubrique Accueil