Chemin et nom de fichier de plus de 255 caractères
10 réponses
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 ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
kurtz_le_pirate
"SEL EI" a écrit dans le message de 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
"SEL EI" <SELEI@discussions.microsoft.com> a écrit dans le message de
news: 46380AE2-AFAB-4F37-A35B-645AA43C077A@microsoft.com...
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.
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
"SEL EI" a écrit dans le message de 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
"SEL EI" <SELEI@discussions.microsoft.com> a écrit dans le message de
news:46380AE2-AFAB-4F37-A35B-645AA43C077A@microsoft.com...
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
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
On Thu, 12 Apr 2007 11:55:40 +0200, "kurtz_le_pirate" wrote:
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
On Thu, 12 Apr 2007 11:55:40 +0200, "kurtz_le_pirate"
<kurtzlepirate@yahoo.fr> wrote:
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
On Thu, 12 Apr 2007 11:55:40 +0200, "kurtz_le_pirate" wrote:
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
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
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 ...
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]
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" wrote:
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
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" <Nina@nospam> a écrit dans le message de
news:n6bs13h35ghd6buvfg5tfm4kaic7qju26j@4ax.com...
On Thu, 12 Apr 2007 11:55:40 +0200, "kurtz_le_pirate"
<kurtzlepirate@yahoo.fr> wrote:
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
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" wrote:
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]
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]" a écrit dans le message de 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" wrote:
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
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]" <mthibaut@hotmail.fr> a écrit dans le message de
news:eVHIOVTfHHA.3960@TK2MSFTNGP02.phx.gbl...
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" <Nina@nospam> a écrit dans le message de
news:n6bs13h35ghd6buvfg5tfm4kaic7qju26j@4ax.com...
On Thu, 12 Apr 2007 11:55:40 +0200, "kurtz_le_pirate"
<kurtzlepirate@yahoo.fr> wrote:
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
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]" a écrit dans le message de 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" wrote:
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]
"moi" wrote in message 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" <moi@pas.la.ici> wrote in message
news:OhvWhLRfHHA.4176@TK2MSFTNGP03.phx.gbl...
<...>
... 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.
... 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
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
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 ...
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 ...
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
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
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]
"moi" wrote in message 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
"moi" <moi@pas.la.ici> wrote in message
news:eoeOgHdfHHA.1312@TK2MSFTNGP03.phx.gbl...
<...>
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. :-)
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. :-)
