Ca faisait un bout de temps que je ne m'étais pas cassé les dents sur
OuinOuin mais là, j'ai besoin de l'aide des poilus!
Le PB: Existe t'il une limitation de niveau (nombre) de repertoire
sous NTFS ?
Etant incapable de copier des données depuis une partition NTFS vers
une autre NTFS (message: Impossible de copier Fichier: (pas de nom de
fichier affiché)), j'ai regardé de plus prés mes repertoires/fichiers
et je suis incapable de descendre sur des fichiers ou repertoires en
dessous du 14ème niveau par rapport à la racine du disque ???
Le pire est que depuis le 13éme niveau de répertoire sous la racine,
je vois par exemple d'autres repertoires ou d'autres fichiers mais le
double clic dessus ne donne rien (juste un "ding" de l'OS (XP SP2)).
Le clic droit sur ce dernier niveau me réduit le menu contextuel à 3
items (Ouvrir, Heedit using Hex Work, Envoyer vers). Les trois sont
inopérants (rien ne se passe au clic sauf pour Envoyer vers qui me
déroule son menu habituel mais sans plus..).
Pourtant, à l'origine, je n'ai pas eu de message d'erreur lors de
l'écriture de ces rep et fichiers ???
Le PB: Existe t'il une limitation de niveau (nombre) de repertoire sous NTFS ?
Non, mais la longueur maximale du nom complet d'un fichier ou d'un répertoire (depuis la lettre du lecteur jusqu'au dernier caractère) est de 260 caractères.
Le Fri, 04 May 2007 01:08:44 +0200, Bd écrivait:
Le PB: Existe t'il une limitation de niveau (nombre) de repertoire
sous NTFS ?
Non, mais la longueur maximale du nom complet d'un fichier ou d'un
répertoire (depuis la lettre du lecteur jusqu'au dernier caractère)
est de 260 caractères.
Le PB: Existe t'il une limitation de niveau (nombre) de repertoire sous NTFS ?
Non, mais la longueur maximale du nom complet d'un fichier ou d'un répertoire (depuis la lettre du lecteur jusqu'au dernier caractère) est de 260 caractères.
Christian THOMAS
> Le Fri, 04 May 2007 01:08:44 +0200, Bd écrivait:
Le PB: Existe t'il une limitation de niveau (nombre) de repertoire sous NTFS ?
Non, mais la longueur maximale du nom complet d'un fichier ou d'un répertoire (depuis la lettre du lecteur jusqu'au dernier caractère) est de 260 caractères.
Ce serait pas plutôt 256 ? (0 à 255). Ce serait plus logique.
-- Remplacer NS par ORG pour les réponses en direct
Christian
> Le Fri, 04 May 2007 01:08:44 +0200, Bd écrivait:
Le PB: Existe t'il une limitation de niveau (nombre) de repertoire
sous NTFS ?
Non, mais la longueur maximale du nom complet d'un fichier ou d'un
répertoire (depuis la lettre du lecteur jusqu'au dernier caractère)
est de 260 caractères.
Ce serait pas plutôt 256 ? (0 à 255). Ce serait plus logique.
--
Remplacer NS par ORG pour les réponses en direct
> Le Fri, 04 May 2007 01:08:44 +0200, Bd écrivait:
Le PB: Existe t'il une limitation de niveau (nombre) de repertoire sous NTFS ?
Non, mais la longueur maximale du nom complet d'un fichier ou d'un répertoire (depuis la lettre du lecteur jusqu'au dernier caractère) est de 260 caractères.
Ce serait pas plutôt 256 ? (0 à 255). Ce serait plus logique.
-- Remplacer NS par ORG pour les réponses en direct
Christian
Blaise Potard
Le Fri, 04 May 2007 06:05:52 +0200, Eric Rossé a écrit:
Le Fri, 04 May 2007 01:08:44 +0200, Bd écrivait:
Le PB: Existe t'il une limitation de niveau (nombre) de repertoire sous NTFS ?
Non, mais la longueur maximale du nom complet d'un fichier ou d'un répertoire (depuis la lettre du lecteur jusqu'au dernier caractère) est de 260 caractères.
Je pense que cette limitation est totalement artificielle. En principe, en NTFS la longueur maximale d'un nom est de 32000 caractères unicodes (et 255 pour chaque niveau d'arborescence). Si il y a ce genre de problème, c'est uniquement les explorateurs qui sont mauvais et n'utilisent que des chemins absolus, alors que (je suppose) en utilisant des chemins relatifs ils pourraient faire sauter cette barrière sans aucune difficulté. Il est possible que certains comme Total Commander le fassent, je ne sais pas, j'ai pas essayé. J'ai simplement vu que l'utilisation de partition NTFS sous linux n'a pas de limitation de ce genre (j'ai crée un chemin qui fait 2800 caractères sans aucune difficulté, et je le manipule sans problème), ce qui est tout de même un comble ! :)
Le Fri, 04 May 2007 06:05:52 +0200, Eric Rossé a écrit:
Le Fri, 04 May 2007 01:08:44 +0200, Bd écrivait:
Le PB: Existe t'il une limitation de niveau (nombre) de repertoire
sous NTFS ?
Non, mais la longueur maximale du nom complet d'un fichier ou d'un
répertoire (depuis la lettre du lecteur jusqu'au dernier caractère)
est de 260 caractères.
Je pense que cette limitation est totalement artificielle. En principe, en
NTFS la longueur maximale d'un nom est de 32000 caractères unicodes (et 255
pour chaque niveau d'arborescence). Si il y a ce genre de problème, c'est
uniquement les explorateurs qui sont mauvais et n'utilisent que des
chemins absolus, alors que (je suppose) en utilisant des chemins relatifs
ils pourraient faire sauter cette barrière sans aucune difficulté. Il est
possible que certains comme Total Commander le fassent, je ne sais pas,
j'ai pas essayé. J'ai simplement vu que l'utilisation de partition NTFS
sous linux n'a pas de limitation de ce genre (j'ai crée un chemin qui fait
2800 caractères sans aucune difficulté, et je le manipule sans problème),
ce qui est tout de même un comble ! :)
Le Fri, 04 May 2007 06:05:52 +0200, Eric Rossé a écrit:
Le Fri, 04 May 2007 01:08:44 +0200, Bd écrivait:
Le PB: Existe t'il une limitation de niveau (nombre) de repertoire sous NTFS ?
Non, mais la longueur maximale du nom complet d'un fichier ou d'un répertoire (depuis la lettre du lecteur jusqu'au dernier caractère) est de 260 caractères.
Je pense que cette limitation est totalement artificielle. En principe, en NTFS la longueur maximale d'un nom est de 32000 caractères unicodes (et 255 pour chaque niveau d'arborescence). Si il y a ce genre de problème, c'est uniquement les explorateurs qui sont mauvais et n'utilisent que des chemins absolus, alors que (je suppose) en utilisant des chemins relatifs ils pourraient faire sauter cette barrière sans aucune difficulté. Il est possible que certains comme Total Commander le fassent, je ne sais pas, j'ai pas essayé. J'ai simplement vu que l'utilisation de partition NTFS sous linux n'a pas de limitation de ce genre (j'ai crée un chemin qui fait 2800 caractères sans aucune difficulté, et je le manipule sans problème), ce qui est tout de même un comble ! :)
Eric Rossé
Le Fri, 04 May 2007 07:26:34 +0200, Christian THOMAS écrivait:
Non, mais la longueur maximale du nom complet d'un fichier ou d'un répertoire (depuis la lettre du lecteur jusqu'au dernier caractère) est de 260 caractères.
Ce serait pas plutôt 256 ? (0 à 255). Ce serait plus logique.
Non, c'est bien 260... J'ai dû savoir pourquoi dans une autre vie et j'ai la flemme de rechercher dans msdn la raison.
Le Fri, 04 May 2007 07:26:34 +0200, Christian THOMAS écrivait:
Non, mais la longueur maximale du nom complet d'un fichier ou d'un
répertoire (depuis la lettre du lecteur jusqu'au dernier caractère)
est de 260 caractères.
Ce serait pas plutôt 256 ? (0 à 255). Ce serait plus logique.
Non, c'est bien 260... J'ai dû savoir pourquoi dans une autre
vie et j'ai la flemme de rechercher dans msdn la raison.
Le Fri, 04 May 2007 07:26:34 +0200, Christian THOMAS écrivait:
Non, mais la longueur maximale du nom complet d'un fichier ou d'un répertoire (depuis la lettre du lecteur jusqu'au dernier caractère) est de 260 caractères.
Ce serait pas plutôt 256 ? (0 à 255). Ce serait plus logique.
Non, c'est bien 260... J'ai dû savoir pourquoi dans une autre vie et j'ai la flemme de rechercher dans msdn la raison.
Eric Rossé
Le 04 May 2007 06:38:19 GMT, Blaise Potard écrivait:
Je pense que cette limitation est totalement artificielle.
C'est vraissemblable... comme beaucoup en informatique ;-).
J'ai simplement vu que l'utilisation de partition NTFS sous linux n'a pas de limitation de ce genre (j'ai crée un chemin qui fait 2800 caractères sans aucune difficulté, et je le manipule sans problème), ce qui est tout de même un comble ! :)
Si on fait du NTFS sous Linux, c'est quelque part qu'on utilise du windows... A quoi sert de créer un chemin aussi grand si windows ne peut s'en servir par la suite ?
Le 04 May 2007 06:38:19 GMT, Blaise Potard écrivait:
Je pense que cette limitation est totalement artificielle.
C'est vraissemblable... comme beaucoup en informatique ;-).
J'ai simplement vu que l'utilisation de partition NTFS sous linux
n'a pas de limitation de ce genre (j'ai crée un chemin qui fait
2800 caractères sans aucune difficulté, et je le manipule sans problème),
ce qui est tout de même un comble ! :)
Si on fait du NTFS sous Linux, c'est quelque part qu'on
utilise du windows... A quoi sert de créer un chemin
aussi grand si windows ne peut s'en servir par la suite ?
Le 04 May 2007 06:38:19 GMT, Blaise Potard écrivait:
Je pense que cette limitation est totalement artificielle.
C'est vraissemblable... comme beaucoup en informatique ;-).
J'ai simplement vu que l'utilisation de partition NTFS sous linux n'a pas de limitation de ce genre (j'ai crée un chemin qui fait 2800 caractères sans aucune difficulté, et je le manipule sans problème), ce qui est tout de même un comble ! :)
Si on fait du NTFS sous Linux, c'est quelque part qu'on utilise du windows... A quoi sert de créer un chemin aussi grand si windows ne peut s'en servir par la suite ?
Blaise Potard
Eric Rossé a écrit :
Si on fait du NTFS sous Linux, c'est quelque part qu'on utilise du windows... A quoi sert de créer un chemin aussi grand si windows ne peut s'en servir par la suite ?
À pas grand chose, bien évidemment. Ce qui est étrange, c'est de faire un filesystem puissant, mais de faire une API merdique qui ne permet d'utiliser qu'1% de ses capacités. Tu vas me dire que l'API a été écrite du temps de la FAT et jamais modifiée depuis, mais tout de même... (Remarque, il est vrai que si beaucoup de programmes ont hard-codé la taille du chemin maximal, on peut être sûr que si un jour ils modifient l'API pour permettre l'ouverture de fichiers ayant un chemin plus long, ça risque de provoquer des catastrophes d'ampleur dépassant largement celle du légendaire bug de l'an 2000...)
Eric Rossé a écrit :
Si on fait du NTFS sous Linux, c'est quelque part qu'on
utilise du windows... A quoi sert de créer un chemin
aussi grand si windows ne peut s'en servir par la suite ?
À pas grand chose, bien évidemment. Ce qui est étrange, c'est de faire
un filesystem puissant, mais de faire une API merdique qui ne permet
d'utiliser qu'1% de ses capacités. Tu vas me dire que l'API a été écrite
du temps de la FAT et jamais modifiée depuis, mais tout de même...
(Remarque, il est vrai que si beaucoup de programmes ont hard-codé la
taille du chemin maximal, on peut être sûr que si un jour ils modifient
l'API pour permettre l'ouverture de fichiers ayant un chemin plus long,
ça risque de provoquer des catastrophes d'ampleur dépassant largement
celle du légendaire bug de l'an 2000...)
Si on fait du NTFS sous Linux, c'est quelque part qu'on utilise du windows... A quoi sert de créer un chemin aussi grand si windows ne peut s'en servir par la suite ?
À pas grand chose, bien évidemment. Ce qui est étrange, c'est de faire un filesystem puissant, mais de faire une API merdique qui ne permet d'utiliser qu'1% de ses capacités. Tu vas me dire que l'API a été écrite du temps de la FAT et jamais modifiée depuis, mais tout de même... (Remarque, il est vrai que si beaucoup de programmes ont hard-codé la taille du chemin maximal, on peut être sûr que si un jour ils modifient l'API pour permettre l'ouverture de fichiers ayant un chemin plus long, ça risque de provoquer des catastrophes d'ampleur dépassant largement celle du légendaire bug de l'an 2000...)
Gump
| Etant incapable de copier des données depuis une partition NTFS vers | une autre NTFS (message: Impossible de copier Fichier: (pas de nom de | fichier affiché)), j'ai regardé de plus prés mes repertoires/fichiers | et je suis incapable de descendre sur des fichiers ou repertoires en | dessous du 14ème niveau par rapport à la racine du disque ???
Une hiérarchie de 14 niveaux...ça fait quand même beaucoup !
Gump
| Etant incapable de copier des données depuis une partition NTFS vers
| une autre NTFS (message: Impossible de copier Fichier: (pas de nom de
| fichier affiché)), j'ai regardé de plus prés mes repertoires/fichiers
| et je suis incapable de descendre sur des fichiers ou repertoires en
| dessous du 14ème niveau par rapport à la racine du disque ???
Une hiérarchie de 14 niveaux...ça fait quand même beaucoup !
| Etant incapable de copier des données depuis une partition NTFS vers | une autre NTFS (message: Impossible de copier Fichier: (pas de nom de | fichier affiché)), j'ai regardé de plus prés mes repertoires/fichiers | et je suis incapable de descendre sur des fichiers ou repertoires en | dessous du 14ème niveau par rapport à la racine du disque ???
Une hiérarchie de 14 niveaux...ça fait quand même beaucoup !
Gump
Philippe
"Gump" a écrit dans le message de news: 463b99e5$0$5079$
| Etant incapable de copier des données depuis une partition NTFS vers | une autre NTFS (message: Impossible de copier Fichier: (pas de nom de | fichier affiché)), j'ai regardé de plus prés mes repertoires/fichiers | et je suis incapable de descendre sur des fichiers ou repertoires en | dessous du 14ème niveau par rapport à la racine du disque ???
Une hiérarchie de 14 niveaux...ça fait quand même beaucoup !
Gump
Cher ami, dans les entreprises il est courant de rencontrer ces longueurs !
à tel point que même ayant les droits sur le serveur les utilisateurs ne peuvent plus écrire ou copier quoi que ce soit tellement le chemin est long. Il suffit de remonter d'une ou deux hiérarchies et les copies peuvent se faire...
Le soucis est que depuis qu'on leur a donné le droit au noms longs, ils en abusent.
"Gump" <gump@free.fr> a écrit dans le message de news:
463b99e5$0$5079$ba4acef3@news.orange.fr...
| Etant incapable de copier des données depuis une partition NTFS vers
| une autre NTFS (message: Impossible de copier Fichier: (pas de nom de
| fichier affiché)), j'ai regardé de plus prés mes repertoires/fichiers
| et je suis incapable de descendre sur des fichiers ou repertoires en
| dessous du 14ème niveau par rapport à la racine du disque ???
Une hiérarchie de 14 niveaux...ça fait quand même beaucoup !
Gump
Cher ami, dans les entreprises il est courant de rencontrer ces longueurs !
à tel point que même ayant les droits sur le serveur les utilisateurs ne
peuvent plus écrire ou copier quoi que ce soit tellement le chemin est long.
Il suffit de remonter d'une ou deux hiérarchies et les copies peuvent se
faire...
Le soucis est que depuis qu'on leur a donné le droit au noms longs, ils en
abusent.
"Gump" a écrit dans le message de news: 463b99e5$0$5079$
| Etant incapable de copier des données depuis une partition NTFS vers | une autre NTFS (message: Impossible de copier Fichier: (pas de nom de | fichier affiché)), j'ai regardé de plus prés mes repertoires/fichiers | et je suis incapable de descendre sur des fichiers ou repertoires en | dessous du 14ème niveau par rapport à la racine du disque ???
Une hiérarchie de 14 niveaux...ça fait quand même beaucoup !
Gump
Cher ami, dans les entreprises il est courant de rencontrer ces longueurs !
à tel point que même ayant les droits sur le serveur les utilisateurs ne peuvent plus écrire ou copier quoi que ce soit tellement le chemin est long. Il suffit de remonter d'une ou deux hiérarchies et les copies peuvent se faire...
Le soucis est que depuis qu'on leur a donné le droit au noms longs, ils en abusent.
Blaise Potard
Le Sat, 05 May 2007 04:37:35 +0200, Philippe a écrit:
Le soucis est que depuis qu'on leur a donné le droit au noms longs, ils en abusent.
Il suffit de leur expliquer que s'ils veulent des noms vraiment long, ils sont *obligés* de passer sous Unix, les joujoux comme Windows® n'étant pas vraiment prévus pour. Ça devrait les calmer un peu (ou les encourager à suivre la bonne voie).
Le Sat, 05 May 2007 04:37:35 +0200, Philippe a écrit:
Le soucis est que depuis qu'on leur a donné le droit au noms longs, ils en
abusent.
Il suffit de leur expliquer que s'ils veulent des noms vraiment long, ils
sont *obligés* de passer sous Unix, les joujoux comme Windows® n'étant pas
vraiment prévus pour. Ça devrait les calmer un peu (ou les encourager à
suivre la bonne voie).
Le Sat, 05 May 2007 04:37:35 +0200, Philippe a écrit:
Le soucis est que depuis qu'on leur a donné le droit au noms longs, ils en abusent.
Il suffit de leur expliquer que s'ils veulent des noms vraiment long, ils sont *obligés* de passer sous Unix, les joujoux comme Windows® n'étant pas vraiment prévus pour. Ça devrait les calmer un peu (ou les encourager à suivre la bonne voie).
Sergio
Blaise Potard a formulé la demande :
Le Sat, 05 May 2007 04:37:35 +0200, Philippe a écrit:
Le soucis est que depuis qu'on leur a donné le droit au noms longs, ils en abusent.
Il suffit de leur expliquer que s'ils veulent des noms vraiment long, ils sont *obligés* de passer sous Unix, les joujoux comme Windows® n'étant pas vraiment prévus pour. Ça devrait les calmer un peu (ou les encourager à suivre la bonne voie).
Il y a eu des Unix beaucoup plus timorés que ça... À ton avis pourquoi les répertoires standards s'appellent /bin /usr /tmp /var /etc ?
Le Sat, 05 May 2007 04:37:35 +0200, Philippe a écrit:
Le soucis est que depuis qu'on leur a donné le droit au noms longs, ils en
abusent.
Il suffit de leur expliquer que s'ils veulent des noms vraiment long, ils
sont *obligés* de passer sous Unix, les joujoux comme Windows® n'étant pas
vraiment prévus pour. Ça devrait les calmer un peu (ou les encourager à
suivre la bonne voie).
Il y a eu des Unix beaucoup plus timorés que ça... À ton avis pourquoi
les répertoires standards s'appellent /bin /usr /tmp /var /etc ?
Le Sat, 05 May 2007 04:37:35 +0200, Philippe a écrit:
Le soucis est que depuis qu'on leur a donné le droit au noms longs, ils en abusent.
Il suffit de leur expliquer que s'ils veulent des noms vraiment long, ils sont *obligés* de passer sous Unix, les joujoux comme Windows® n'étant pas vraiment prévus pour. Ça devrait les calmer un peu (ou les encourager à suivre la bonne voie).
Il y a eu des Unix beaucoup plus timorés que ça... À ton avis pourquoi les répertoires standards s'appellent /bin /usr /tmp /var /etc ?
