Chemin et nom de fichier de plus de 255 caractères

Le
SEL EI
Bonjour,

Sur un serveur 2003 SP1 avec partition NTFS lorsque le chemin d'accés avec
le nom de fichier fait plus de 255 caractères le fichier n'est plus
sauvegardé et le comportement par l'explorateur est différent (Clic droit sur
le fichier le menu est différent : Copier renommer accés au propriétés
impossible)


Mes questions :
Est-on limité à 255 caractères sur un serveur 2003 avec des partitions NTFS ?
Si non, quelle est la solution pour repousser la limite des 255 caractères ?

Merci pour votre aide

Cordialement.

Serge
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
kurtz_le_pirate
Le #723351
"SEL EI" news:
Bonjour,

Sur un serveur 2003 SP1 avec partition NTFS lorsque le chemin
d'accés avec
le nom de fichier fait plus de 255 caractères le fichier n'est plus
sauvegardé et le comportement par l'explorateur est différent (Clic
droit sur
le fichier le menu est différent : Copier renommer accés au
propriétés
impossible)


Mes questions :
Est-on limité à 255 caractères sur un serveur 2003 avec des
partitions NTFS ?
Si non, quelle est la solution pour repousser la limite des 255
caractères ?


théoriquement je ne sais pas mais pratiquement OUI. j'ai les mêmes
problèmes pour accéder à ces fichiers.

par contre, pas de problème au niveau des sauvegardes.

--
klp

Jean-Claude BELLAMY
Le #723350
"SEL EI" news:
Bonjour,

Sur un serveur 2003 SP1 avec partition NTFS lorsque le chemin d'accés avec
le nom de fichier fait plus de 255 caractères le fichier n'est plus
sauvegardé et le comportement par l'explorateur est différent (Clic droit
sur
le fichier le menu est différent : Copier renommer accés au propriétés
impossible)


Mes questions :
Est-on limité à 255 caractères sur un serveur 2003 avec des partitions
NTFS ?
La taille maximale des noms de fichiers est officiellement égale à 260

caractères
Cette valeur tient compte de TOUT :
lettre de disque (avec ":") ou nom UNC (avec \),
sous-répertoires,
nom de fichier (ou dossier),
extension (avec le "."),
et tous les "" séparateurs


Cela correspond à la valeur de la constante MAX_PATH utilisée partout dans
les API de Windows et qui est égale à 260.

Dans Windef.h :
#define MAX_PATH 260


Dans MAPIWin.h :
#define MAX_PATH 260


et dans le cas de programme en VB ou VB.NET, on retrouve presque partout
cette déclaration :
private const int MAX_PATH = 260;

En Delphi (dans System.pas)
MAX_PATH = 260;

MAIS malgré cela, j'ai trouvé des articles (y compris du MSDN) où il est
question de 255 caractères, voire 256, et parfois 259 dans le cas de Windows
95... !
Cependant, la valeur de 260 n'est jamais dépassée, quel que soit l'OS
Microsoft.

Il y a intérêt cependant à rester en dessous, à savoir 255, car cela dépend
des traitements auxquels on peut être confrontés.(255 est le nombre maximal
tenant sur un octet).


--
May the Force be with You!
La Connaissance s'accroît quand on la partage
----------------------------------------------------------
Jean-Claude BELLAMY [MVP]
http://www.bellamyjc.org ou http://jc.bellamy.free.fr

Nina Popravka
Le #723349
On Thu, 12 Apr 2007 11:55:40 +0200, "kurtz_le_pirate"

théoriquement je ne sais pas mais pratiquement OUI. j'ai les mêmes
problèmes pour accéder à ces fichiers.


Pratiquement, j'en ai aussi souvent vu, comme tout le monde, avec des
problèmes de longueur de *chemins d'accès*.
Je n'ai jamais réussi à reproduire le phénomène à la main (pas faute
d'avoir essayé...), mais on y arrive assez bien et aléatoirement en
décompactant des dossiers avec des noms longs comme le bras dans
d'autres dossiers avec des noms longs comme le bras aussi.
--
Nina

moi
Le #723348
Notre ami Jean-Claude BELLAMY tapota :

(...)
Cela correspond à la valeur de la constante MAX_PATH utilisée
partout
dans les API de Windows et qui est égale à 260.

(...)

Il y a intérêt cependant à rester en dessous, à savoir 255, car
cela
dépend des traitements auxquels on peut être confrontés.(255 est le
nombre maximal tenant sur un octet).


Bonjour,

... et pourtant, dans le document robocopy.doc
qui tient lieu de mode d'emploi détaillé
pour l'outil du même nom,
on peut lire :

(...)
dans la section "Processing a Directory Tree"
(...)
"By default Robocopy will handle file and directory path names
up to almost 32,000 characters in length.
If for any reason you wish to disable
this support for very long path names,
use the /256 switch. This causes Robocopy
to revert to normal path name semantics,
and a maximum path name length of 256 characters. "
(...)

Il faut noter que cette option /256 n'est pas documentée
dans le tableau du même document
qui reprend la liste des switchs disponibles ...

32 000 caractères ça fait un sacré chemin ....

HB

Michaël THIBAUT [MVP]
Le #723343
Bonsoir Nina,

Une autre solution pour reproduire cela c'est de créer une arborescence de
dossiers longue comme les champs Elysées. Il te suffit alors de partager le
dernier répertoire créé dans cet arborescence puis de se connecter à ce
partage et de rajouter des répertoires et/ou des fichiers tout aussi longs !
Résultat garantie ! LOL Reste plus ensuite qu'à expérimenter une sauvegarde
du lecteur qui contient cette jolie arborescence! erreurs garanties !

--
Cordialement,
Michaël

MVP Windows Server - Directory Services
MCSA/MCSE 2003 Security
MCSA/MCSE 2003 Messaging

Mon blog:
http://mthibaut.over-blog.com

"Nina Popravka" a écrit dans le message de
news:
On Thu, 12 Apr 2007 11:55:40 +0200, "kurtz_le_pirate"

théoriquement je ne sais pas mais pratiquement OUI. j'ai les mêmes
problèmes pour accéder à ces fichiers.


Pratiquement, j'en ai aussi souvent vu, comme tout le monde, avec des
problèmes de longueur de *chemins d'accès*.
Je n'ai jamais réussi à reproduire le phénomène à la main (pas faute
d'avoir essayé...), mais on y arrive assez bien et aléatoirement en
décompactant des dossiers avec des noms longs comme le bras dans
d'autres dossiers avec des noms longs comme le bras aussi.
--
Nina



Thierry DEMAN [MVP]
Le #723062
Bonsoir,

comme Kurtz, je n'ai pas vu de soucis au niveau de la sauvegarde.
En revanche, il y en a dans les scripts et dans l'explorer sur le serveur.

Au niveau des scripts, il faut tester la longueur des chemins utilisés et ne
pas gérer les noms trop longs.

En cas de problème, la solution est de donc créer un partage, et d'utiliser
ce partage pour accéder à la suite.

A+
--
Thierry DEMAN-BARCELÒ
MVP Exchange, SQL/Server
http://base.faqexchange.info http://www.faqexchange.info
http://ISAFirewalls.org
"Michaël THIBAUT [MVP]" news:
Bonsoir Nina,

Une autre solution pour reproduire cela c'est de créer une arborescence de
dossiers longue comme les champs Elysées. Il te suffit alors de partager
le dernier répertoire créé dans cet arborescence puis de se connecter à ce
partage et de rajouter des répertoires et/ou des fichiers tout aussi longs
! Résultat garantie ! LOL Reste plus ensuite qu'à expérimenter une
sauvegarde du lecteur qui contient cette jolie arborescence! erreurs
garanties !

--
Cordialement,
Michaël

MVP Windows Server - Directory Services
MCSA/MCSE 2003 Security
MCSA/MCSE 2003 Messaging

Mon blog:
http://mthibaut.over-blog.com

"Nina Popravka" a écrit dans le message de
news:
On Thu, 12 Apr 2007 11:55:40 +0200, "kurtz_le_pirate"

théoriquement je ne sais pas mais pratiquement OUI. j'ai les mêmes
problèmes pour accéder à ces fichiers.


Pratiquement, j'en ai aussi souvent vu, comme tout le monde, avec des
problèmes de longueur de *chemins d'accès*.
Je n'ai jamais réussi à reproduire le phénomène à la main (pas faute
d'avoir essayé...), mais on y arrive assez bien et aléatoirement en
décompactant des dossiers avec des noms longs comme le bras dans
d'autres dossiers avec des noms longs comme le bras aussi.
--
Nina






Jacques Barathon [MS]
Le #722783
"moi" news:
... et pourtant, dans le document robocopy.doc
qui tient lieu de mode d'emploi détaillé
pour l'outil du même nom,
on peut lire :

(...)
dans la section "Processing a Directory Tree"
(...)
"By default Robocopy will handle file and directory path names
up to almost 32,000 characters in length.
If for any reason you wish to disable
this support for very long path names,
use the /256 switch. This causes Robocopy
to revert to normal path name semantics,
and a maximum path name length of 256 characters. "


Il faut distinguer la capacité pour NTFS de stocker des noms de chemin très
longs (32000 caractères semble être une limite raisonnable), et la limite
imposée par les API Windows aux applications qui veulent accéder à une
partition NTFS.

En gros, tant que tu as une application qui n'utilise pas les API Windows
d'accès aux fichiers, tu as une chance de pouvoir aller au-delà de la limite
des 260 caractères. Mais dès que tu passeras par une application qui utilise
ces API (cas de l'immense majorité à mon humble avis), tu seras bloqué
au-delà de cette limite. C'est donc bien dans un souci de compatibilité
qu'on recommande de se limiter à 260 caractères - tout compris, comme
l'expliquait Jean-Claude.

Jacques

moi
Le #722782
Notre ami Jacques Barathon [MS] tapota :

(...)>
Il faut distinguer la capacité pour NTFS de stocker des noms de
chemin très longs (32000 caractères semble être une limite
raisonnable), et la limite imposée par les API Windows aux
applications qui veulent accéder à une partition NTFS.

(...)


C'est aussi ce qui me semblait.

Peu de programmes à l'heure actuelle utilisent
pleinement les possibilités déjà anciennes du NTFS
en ce qui concerne de la longueur d'un chemin...
Et le pire, c'est que les API de windows
en sont la principale cause ...

On croit rêver ...

HB

Nina Popravka
Le #722777
On Fri, 13 Apr 2007 14:51:35 +0200, "Jacques Barathon [MS]"

En gros, tant que tu as une application qui n'utilise pas les API Windows
d'accès aux fichiers, tu as une chance de pouvoir aller au-delà de la limite
des 260 caractères. Mais dès que tu passeras par une application qui utilise
ces API (cas de l'immense majorité à mon humble avis), tu seras bloqué
au-delà de cette limite.


Ah, une explication claire qui m'enchante, et un des grands mystères
de l'Univers résolu.
Merci :-)
--
Nina

Jacques Barathon [MS]
Le #722776
"moi" news:
Peu de programmes à l'heure actuelle utilisent
pleinement les possibilités déjà anciennes du NTFS
en ce qui concerne de la longueur d'un chemin...
Et le pire, c'est que les API de windows
en sont la principale cause ...

On croit rêver ...


Ce qui fait rêver, c'est le nombre de "choix" imposés aux développeurs de
Microsoft par les contraintes liées à la compatibilité avec le parc
applicatif existant. Faire évoluer les API Windows sans foutre par terre les
millions d'applis déjà écrites à travers le monde n'est pas une mince
affaire, et cet exemple de longueur de chemin n'est qu'un exemple parmi des
milliers.

Pour ta culture, cette question sur MAX_PATH est une des plus fréquemment
posées sur nos listes de discussion internes qui traitent de Windows. La
réponse est invariablement la même: la possibilité de changer cette
constante a déjà été examinée en long, en large et en travers, mais les
dépendances sont trop importantes et l'impact potentiel trop négatif. Ca
changera peut-être dans une prochaine version de Windows, mais je ne
prendrai pas de pari sur le sujet. :-)

Jacques

Publicité
Poster une réponse
Anonyme