énigme lors de transferts par ftp dans un répertoire d'une partition
fat32 de ma machine (noyau 2.6.15) : impossible de récupérer l'un d'eux
(erreur : ne peut ouvrir le fichier local, argument invalide).
J'ai réussi à le télécharger sur une autre partition en ext3 mais
ensuite toujours impossible de le transférer sur la partition fat32
(erreur : impossible d'écrire dans le fichier ou de l'ouvrir suivant la
manip).
Le fichier récalcitrant s'appelle 'AUX.HDF.tar.gz'. Est-ce que le
problème pourrait avoir une relation au fait que 'AUX' est un nom
spécial pour MSDOS et Windows (tout comme LPT, CON, COM...) ?
--
Sébastien Kirche
qualités intrinsèques des fat32 (les fichiers ont toujours un multiple de 32 ou 64k
Non. Ça dépend de la taille du volume. La taille de bloc par défaut en FAT32 est 4 Kio.
Ceci dit, Linux a aussi des noms réservés.
Lesquels, par exemple ?
Denis Beauregard
Le Sun, 18 Mar 2007 22:50:55 +0100, Sébastien Monbrun aka TiChou écrivait dans fr.comp.os.linux.configuration:
Dans le message <news:, *Denis Beauregard* tapota sur f.c.o.l.configuration :
Sauf que les systèmes de fichiers sous Windows n'ont pas de telles limitations (celle d'interdire les noms de fichiers CON, AUX, LPT1, PRN, etc.). Cette limitation se situe au niveau système (noyau me semble-t-il) et pas sur toutes les versions de Windows.
Ah oui ?
Oui, certain. Connaissez-vous l'origine de cette limitation ?
Je ne sais pas si c'est dans Windows XP, mais je ne vois pas pourquoi on l'aurait enlever.
Avec Windows 98:
Lequel ?
98SE
Mais cela existait dans DOS depuis longtemps.
E:>echo >toto
E:>copy toto devcon ECHO est actif 1 fichier(s) copié(s)
E:>copy toto con ECHO est actif 1 fichier(s) copié(s)
E:>
Dans DOS, on a codé /dev/con à la manière Windows (/ devient ). Unix datant de 1969 et DOS de 1979/1980, il me semble évident que le concept vient de Unix. On l'a simplement adapté (Microsoft est bien connu pour refaire les choses à sa façon en copiant souvent les autres). Dans un vieux DOS, on pouvait remplacer le / des options par un -, et cela permettait de taper copy toto /dev/con, mais cela semble avoir disparu (après DOS 4 ou 5 je pense). Mais au niveau interne, dans un logiciel écrit en C++ par exemple, on pourrait très bien écrire:
fp = fopen ("/dev/con", "w");
et cela fonctionnerait dans DOS, Windows et Linux sans distinction.
[...]
Inutile, je connais les limitations ou non des différentes versions de Windows 98.
Le message d'erreur est peut-être différent, mais la limitation est là. Peu importe sur quelle version de Windows
Non, justement, pas peu importe quelle version de Windows.
Je veux dire que peu importe quelle version de Windows le permet, on a voulu conserver une certaine compatibilité. Donc, on a étendu la règle à Linux et les partitions fat32 par souci de compatibilité avec au moins DOS 2 à Windows 98SE. Je n'ai pas de Windows XP pour tester, mais je vois mal pourquoi on aurait cessé de l'interdire du côté Win XP pour les disques en FAT32 (NTFS est une autre histoire car Win 98 n'est pas supposé savoir comment lire ou écrire en NTFS).
cela ne marche pas, on a la même limitation partout.
Non.
De plus, cela vient de Unix.
Hein ? Quoi donc ?
les devices avec des noms réservés. Les /dev/con etc. se sont retrouvés dans DOS puis Windows, avec et sans le /dev/ (devenu dev )
Quant à la liste des devices, dans DOS, il y avait un tableau en mémoire avec les noms réservés. Je l'utilisais pour faire mes propres devices il y a presque 20 ans. Comme je n'avais pas trouvé la façon directe d'ajouter un device, j'avais analysé la mémoire du DOS pour trouver un pointeur avec le début des devices, mais pour trouver ce pointeur, il fallait que j'en ajoute un au moment du démarrage.
Denis
Le Sun, 18 Mar 2007 22:50:55 +0100, Sébastien Monbrun aka TiChou
<gro.uohcit@uohcit> écrivait dans fr.comp.os.linux.configuration:
Dans le message <news:14erv2p87kb0kgr055d90r0bouvb2kg5km@4ax.com>,
*Denis Beauregard* tapota sur f.c.o.l.configuration :
Sauf que les systèmes de fichiers sous Windows n'ont pas de telles
limitations (celle d'interdire les noms de fichiers CON, AUX, LPT1, PRN,
etc.). Cette limitation se situe au niveau système (noyau me semble-t-il)
et pas sur toutes les versions de Windows.
Ah oui ?
Oui, certain. Connaissez-vous l'origine de cette limitation ?
Je ne sais pas si c'est dans Windows XP, mais je ne vois pas pourquoi
on l'aurait enlever.
Avec Windows 98:
Lequel ?
98SE
Mais cela existait dans DOS depuis longtemps.
E:>echo >toto
E:>copy toto devcon
ECHO est actif
1 fichier(s) copié(s)
E:>copy toto con
ECHO est actif
1 fichier(s) copié(s)
E:>
Dans DOS, on a codé /dev/con à la manière Windows (/ devient ). Unix
datant de 1969 et DOS de 1979/1980, il me semble évident que le
concept vient de Unix. On l'a simplement adapté (Microsoft est bien
connu pour refaire les choses à sa façon en copiant souvent les
autres). Dans un vieux DOS, on pouvait remplacer le / des options par
un -, et cela permettait de taper copy toto /dev/con, mais cela semble
avoir disparu (après DOS 4 ou 5 je pense). Mais au niveau interne,
dans un logiciel écrit en C++ par exemple, on pourrait très bien
écrire:
fp = fopen ("/dev/con", "w");
et cela fonctionnerait dans DOS, Windows et Linux sans distinction.
[...]
Inutile, je connais les limitations ou non des différentes versions de
Windows 98.
Le message d'erreur est peut-être différent, mais la limitation est
là. Peu importe sur quelle version de Windows
Non, justement, pas peu importe quelle version de Windows.
Je veux dire que peu importe quelle version de Windows le permet,
on a voulu conserver une certaine compatibilité. Donc, on a étendu
la règle à Linux et les partitions fat32 par souci de compatibilité
avec au moins DOS 2 à Windows 98SE. Je n'ai pas de Windows XP pour
tester, mais je vois mal pourquoi on aurait cessé de l'interdire
du côté Win XP pour les disques en FAT32 (NTFS est une autre histoire
car Win 98 n'est pas supposé savoir comment lire ou écrire en NTFS).
cela ne marche pas, on a la même limitation partout.
Non.
De plus, cela vient de Unix.
Hein ? Quoi donc ?
les devices avec des noms réservés. Les /dev/con etc. se sont
retrouvés dans DOS puis Windows, avec et sans le /dev/ (devenu
dev )
Quant à la liste des devices, dans DOS, il y avait un tableau
en mémoire avec les noms réservés. Je l'utilisais pour faire mes
propres devices il y a presque 20 ans. Comme je n'avais pas trouvé
la façon directe d'ajouter un device, j'avais analysé la mémoire du
DOS pour trouver un pointeur avec le début des devices, mais pour
trouver ce pointeur, il fallait que j'en ajoute un au moment du
démarrage.
Le Sun, 18 Mar 2007 22:50:55 +0100, Sébastien Monbrun aka TiChou écrivait dans fr.comp.os.linux.configuration:
Dans le message <news:, *Denis Beauregard* tapota sur f.c.o.l.configuration :
Sauf que les systèmes de fichiers sous Windows n'ont pas de telles limitations (celle d'interdire les noms de fichiers CON, AUX, LPT1, PRN, etc.). Cette limitation se situe au niveau système (noyau me semble-t-il) et pas sur toutes les versions de Windows.
Ah oui ?
Oui, certain. Connaissez-vous l'origine de cette limitation ?
Je ne sais pas si c'est dans Windows XP, mais je ne vois pas pourquoi on l'aurait enlever.
Avec Windows 98:
Lequel ?
98SE
Mais cela existait dans DOS depuis longtemps.
E:>echo >toto
E:>copy toto devcon ECHO est actif 1 fichier(s) copié(s)
E:>copy toto con ECHO est actif 1 fichier(s) copié(s)
E:>
Dans DOS, on a codé /dev/con à la manière Windows (/ devient ). Unix datant de 1969 et DOS de 1979/1980, il me semble évident que le concept vient de Unix. On l'a simplement adapté (Microsoft est bien connu pour refaire les choses à sa façon en copiant souvent les autres). Dans un vieux DOS, on pouvait remplacer le / des options par un -, et cela permettait de taper copy toto /dev/con, mais cela semble avoir disparu (après DOS 4 ou 5 je pense). Mais au niveau interne, dans un logiciel écrit en C++ par exemple, on pourrait très bien écrire:
fp = fopen ("/dev/con", "w");
et cela fonctionnerait dans DOS, Windows et Linux sans distinction.
[...]
Inutile, je connais les limitations ou non des différentes versions de Windows 98.
Le message d'erreur est peut-être différent, mais la limitation est là. Peu importe sur quelle version de Windows
Non, justement, pas peu importe quelle version de Windows.
Je veux dire que peu importe quelle version de Windows le permet, on a voulu conserver une certaine compatibilité. Donc, on a étendu la règle à Linux et les partitions fat32 par souci de compatibilité avec au moins DOS 2 à Windows 98SE. Je n'ai pas de Windows XP pour tester, mais je vois mal pourquoi on aurait cessé de l'interdire du côté Win XP pour les disques en FAT32 (NTFS est une autre histoire car Win 98 n'est pas supposé savoir comment lire ou écrire en NTFS).
cela ne marche pas, on a la même limitation partout.
Non.
De plus, cela vient de Unix.
Hein ? Quoi donc ?
les devices avec des noms réservés. Les /dev/con etc. se sont retrouvés dans DOS puis Windows, avec et sans le /dev/ (devenu dev )
Quant à la liste des devices, dans DOS, il y avait un tableau en mémoire avec les noms réservés. Je l'utilisais pour faire mes propres devices il y a presque 20 ans. Comme je n'avais pas trouvé la façon directe d'ajouter un device, j'avais analysé la mémoire du DOS pour trouver un pointeur avec le début des devices, mais pour trouver ce pointeur, il fallait que j'en ajoute un au moment du démarrage.
Denis
Denis Beauregard
Le Mon, 19 Mar 2007 00:17:37 +0100, Pascal Hambourg écrivait dans fr.comp.os.linux.configuration:
Salut,
qualités intrinsèques des fat32 (les fichiers ont toujours un multiple de 32 ou 64k
Non. Ça dépend de la taille du volume. La taille de bloc par défaut en FAT32 est 4 Kio.
Avec un petit disque. Mais dès qu'on dépasse 32 Go, c'est 32k du cluster, ce qui donne beaucoup de pertes si on a beaucoup de petits fichiers. Alors, soit on a artificiellement beaucoup de petits disques (moins de 8 Go), soit on a beaucoup de pertes avec des disques récents. ext3 est beaucoup plus performant.
Ceci dit, Linux a aussi des noms réservés.
Lesquels, par exemple ?
tout ce qui est dans /dev
Chez Linux, on a eu la bonne idée de rendre obligatoire le /dev alors que dans DOS, c'était facultatif au départ (depuis DOS 1 ou 2), l'extension étant aussi facultative (con et con.txt sont pareils).
Denis
Le Mon, 19 Mar 2007 00:17:37 +0100, Pascal Hambourg
<boite-a-spam@plouf.fr.eu.org> écrivait dans
fr.comp.os.linux.configuration:
Salut,
qualités intrinsèques des fat32 (les fichiers ont toujours un
multiple de 32 ou 64k
Non. Ça dépend de la taille du volume. La taille de bloc par défaut en
FAT32 est 4 Kio.
Avec un petit disque. Mais dès qu'on dépasse 32 Go, c'est 32k du
cluster, ce qui donne beaucoup de pertes si on a beaucoup
de petits fichiers. Alors, soit on a artificiellement beaucoup de
petits disques (moins de 8 Go), soit on a beaucoup de pertes avec
des disques récents. ext3 est beaucoup plus performant.
Ceci dit, Linux a aussi des noms réservés.
Lesquels, par exemple ?
tout ce qui est dans /dev
Chez Linux, on a eu la bonne idée de rendre obligatoire le /dev alors
que dans DOS, c'était facultatif au départ (depuis DOS 1 ou 2),
l'extension étant aussi facultative (con et con.txt sont pareils).
Le Mon, 19 Mar 2007 00:17:37 +0100, Pascal Hambourg écrivait dans fr.comp.os.linux.configuration:
Salut,
qualités intrinsèques des fat32 (les fichiers ont toujours un multiple de 32 ou 64k
Non. Ça dépend de la taille du volume. La taille de bloc par défaut en FAT32 est 4 Kio.
Avec un petit disque. Mais dès qu'on dépasse 32 Go, c'est 32k du cluster, ce qui donne beaucoup de pertes si on a beaucoup de petits fichiers. Alors, soit on a artificiellement beaucoup de petits disques (moins de 8 Go), soit on a beaucoup de pertes avec des disques récents. ext3 est beaucoup plus performant.
Ceci dit, Linux a aussi des noms réservés.
Lesquels, par exemple ?
tout ce qui est dans /dev
Chez Linux, on a eu la bonne idée de rendre obligatoire le /dev alors que dans DOS, c'était facultatif au départ (depuis DOS 1 ou 2), l'extension étant aussi facultative (con et con.txt sont pareils).
Denis
Sébastien Kirche
Le 19 mars 2007 à 00:44, Denis Beauregard s'est exprimé ainsi :
De plus, cela vient de Unix.
Hein ? Quoi donc ?
les devices avec des noms réservés. Les /dev/con etc. se sont retrouvés dans DOS puis Windows, avec et sans le /dev/ (devenu dev )
C'est la première fois que j'entends parler de devcon. Dans mon souvenir c'était plutôt LPT1: ou AUX: (je viens de voir que les deux points et les majuscules sont optionnels)
D'ailleurs : C:Documents and SettingsSeki>copy devcon toto Le chemin d'accès spécifié est introuvable.
C:Documents and SettingsSeki>copy con toto test ^Z 1 fichier(s) copié(s).
-- Sébastien Kirche
Le 19 mars 2007 à 00:44, Denis Beauregard s'est exprimé ainsi :
De plus, cela vient de Unix.
Hein ? Quoi donc ?
les devices avec des noms réservés. Les /dev/con etc. se sont
retrouvés dans DOS puis Windows, avec et sans le /dev/ (devenu
dev )
C'est la première fois que j'entends parler de devcon. Dans mon
souvenir c'était plutôt LPT1: ou AUX: (je viens de voir que les deux
points et les majuscules sont optionnels)
D'ailleurs :
C:Documents and SettingsSeki>copy devcon toto
Le chemin d'accès spécifié est introuvable.
C:Documents and SettingsSeki>copy con toto
test
^Z
1 fichier(s) copié(s).
Le 19 mars 2007 à 00:44, Denis Beauregard s'est exprimé ainsi :
De plus, cela vient de Unix.
Hein ? Quoi donc ?
les devices avec des noms réservés. Les /dev/con etc. se sont retrouvés dans DOS puis Windows, avec et sans le /dev/ (devenu dev )
C'est la première fois que j'entends parler de devcon. Dans mon souvenir c'était plutôt LPT1: ou AUX: (je viens de voir que les deux points et les majuscules sont optionnels)
D'ailleurs : C:Documents and SettingsSeki>copy devcon toto Le chemin d'accès spécifié est introuvable.
C:Documents and SettingsSeki>copy con toto test ^Z 1 fichier(s) copié(s).
-- Sébastien Kirche
Nicolas George
Pascal Hambourg wrote in message <etkhaq$17oa$:
Ceci dit, Linux a aussi des noms réservés. Lesquels, par exemple ?
Il y a . et .., sans compter que '/' et NUL sont scandaleusement interdits dans les noms de fichiers.
Pascal Hambourg wrote in message <etkhaq$17oa$1@biggoron.nerim.net>:
Ceci dit, Linux a aussi des noms réservés.
Lesquels, par exemple ?
Il y a . et .., sans compter que '/' et NUL sont scandaleusement interdits
dans les noms de fichiers.
Ceci dit, Linux a aussi des noms réservés. Lesquels, par exemple ?
Il y a . et .., sans compter que '/' et NUL sont scandaleusement interdits dans les noms de fichiers.
Le Gaulois
D'ailleurs : C:Documents and SettingsSeki>copy devcon toto Le chemin d'accès spécifié est introuvable.
C:Documents and SettingsSeki>copy con toto test ^Z 1 fichier(s) copié(s).
Les devices (CON, AUX, NUL ...) sont présents dans tous les répertoires qui existent. Cette particularité est utilisée dans les batches pour tester l'existence d'un répertoire. Si on veut utiliser une syntaxe devcon il faut créer le répertoire dev et ça fonctionnera.
D'ailleurs :
C:Documents and SettingsSeki>copy devcon toto
Le chemin d'accès spécifié est introuvable.
C:Documents and SettingsSeki>copy con toto
test
^Z
1 fichier(s) copié(s).
Les devices (CON, AUX, NUL ...) sont présents dans tous les
répertoires qui existent. Cette particularité est utilisée
dans les batches pour tester l'existence d'un répertoire.
Si on veut utiliser une syntaxe devcon il faut créer le
répertoire dev et ça fonctionnera.
D'ailleurs : C:Documents and SettingsSeki>copy devcon toto Le chemin d'accès spécifié est introuvable.
C:Documents and SettingsSeki>copy con toto test ^Z 1 fichier(s) copié(s).
Les devices (CON, AUX, NUL ...) sont présents dans tous les répertoires qui existent. Cette particularité est utilisée dans les batches pour tester l'existence d'un répertoire. Si on veut utiliser une syntaxe devcon il faut créer le répertoire dev et ça fonctionnera.
Nicolas George
Denis Beauregard wrote in message :
Ceci dit, Linux a aussi des noms réservés.
Non, pas dans le sens auquel tu le penses. Il y a bien . et .., mais à part ça, rien n'est réservé : les périphériques apparaisse réellement dans le filesystem, et ce sont leurs attributs particuliers qui en font des périphériques. Le noyau lui-même ne s'intéresse pas le moins du monde à leur nom : tu peux supprimer /dev/null avec un simple rm, recréer une entrée avec les mêmes propriétés dans /usr/lib/games/contretest avec mknod, et tout est dit.
Denis Beauregard wrote in message
<bccrv25t759cs0rtut6fov6ov03gbqfqcg@4ax.com>:
Ceci dit, Linux a aussi des noms réservés.
Non, pas dans le sens auquel tu le penses. Il y a bien . et .., mais à part
ça, rien n'est réservé : les périphériques apparaisse réellement dans le
filesystem, et ce sont leurs attributs particuliers qui en font des
périphériques. Le noyau lui-même ne s'intéresse pas le moins du monde à leur
nom : tu peux supprimer /dev/null avec un simple rm, recréer une entrée avec
les mêmes propriétés dans /usr/lib/games/contretest avec mknod, et tout est
dit.
Non, pas dans le sens auquel tu le penses. Il y a bien . et .., mais à part ça, rien n'est réservé : les périphériques apparaisse réellement dans le filesystem, et ce sont leurs attributs particuliers qui en font des périphériques. Le noyau lui-même ne s'intéresse pas le moins du monde à leur nom : tu peux supprimer /dev/null avec un simple rm, recréer une entrée avec les mêmes propriétés dans /usr/lib/games/contretest avec mknod, et tout est dit.
Matthieu Moy
Nicolas George <nicolas$ writes:
tu peux supprimer /dev/null avec un simple rm, recréer une entrée avec les mêmes propriétés dans /usr/lib/games/contretest avec mknod, et tout est dit.
Oui, ceci dit, c'est un conseil à la http://www.pafoo.net/uninstallglibc/uninstglibc.txt tout ça ;-).
-- Matthieu
Nicolas George <nicolas$george@salle-s.org> writes:
tu peux supprimer /dev/null avec un simple rm, recréer une entrée avec
les mêmes propriétés dans /usr/lib/games/contretest avec mknod, et tout est
dit.
Oui, ceci dit, c'est un conseil à la
http://www.pafoo.net/uninstallglibc/uninstglibc.txt
tout ça ;-).
tu peux supprimer /dev/null avec un simple rm, recréer une entrée avec les mêmes propriétés dans /usr/lib/games/contretest avec mknod, et tout est dit.
Oui, ceci dit, c'est un conseil à la http://www.pafoo.net/uninstallglibc/uninstglibc.txt tout ça ;-).
-- Matthieu
Fabien LE LEZ
On Mon, 19 Mar 2007 10:29:39 +0100, Matthieu Moy :
Oui, ceci dit, c'est un conseil
Ce n'est pas un conseil, juste l'énoncé d'une possibilité.
Je n'ai pas d'accès physique au serveur web sur lequel je viens d'essayer, comment je fais maintenant ? ;-)
(Sans déc', c'est le genre d'expérimentation débile qui prouve, s'il en était besoin, l'utilité des machines virtuelles. Y'a pas très longtemps, j'ai testé la désinstallation de IE sur un Windows XP, i.e. la suppression de toutes les DLL apportées par le prog d'installation d'IE. Le résultat fut à peu près le même...)
On Mon, 19 Mar 2007 10:29:39 +0100, Matthieu Moy :
Oui, ceci dit, c'est un conseil
Ce n'est pas un conseil, juste l'énoncé d'une possibilité.
Je n'ai pas d'accès physique au serveur web sur lequel je viens
d'essayer, comment je fais maintenant ? ;-)
(Sans déc', c'est le genre d'expérimentation débile qui prouve, s'il
en était besoin, l'utilité des machines virtuelles.
Y'a pas très longtemps, j'ai testé la désinstallation de IE sur un
Windows XP, i.e. la suppression de toutes les DLL apportées par le
prog d'installation d'IE. Le résultat fut à peu près le même...)
Je n'ai pas d'accès physique au serveur web sur lequel je viens d'essayer, comment je fais maintenant ? ;-)
(Sans déc', c'est le genre d'expérimentation débile qui prouve, s'il en était besoin, l'utilité des machines virtuelles. Y'a pas très longtemps, j'ai testé la désinstallation de IE sur un Windows XP, i.e. la suppression de toutes les DLL apportées par le prog d'installation d'IE. Le résultat fut à peu près le même...)
Sébastien Kirche
Le 18 mars 2007 à 21:29, Sébastien Monbrun aka TiChou s'est exprimé ainsi :
Elle est montée avec quelles options la partition vfat ?
Le umask est sans doute discutable, mais vu que je ne me souviens pas l'avoir paramétré c'est peut-être un reste de la knoppix initialement installée.
Tu as essayé avec des noms de fichier ayant le même motif mais sans être préfixé par AUX ? Genre ABC.HDF.tar.gz ? Ou alors avec d'autres noms commençant par AUX. ?
Il y a pas mal de noms qui contiennent le motif 'aux' dans le répertoire et ses enfants (et avec un grand nombre de points). Par exemple :
Ces fichiers sont arrivés par ftp, dans le même lot que le fichier récalcitrant.
Par ailleurs echo > AUX.HDF.tar.gz échoue, alors que echo > ABC.HDF.tar.gz fonctionne. Un point intéressant c'est que echo > AUX.autrefichier échoue également (argument invalide).
zsh: argument invalide: /mnt/hda3/AUX.HDF.tar.gz
Je suis étonné par le message d'erreur retourné par zsh. Je me serais plutôt attentu à un message du genre /permission denied/, /no such file or directory/, etc.
Oui, c'est bizarre. Au fait les derniers essais ont été fait par root. -- Sébastien Kirche
Le 18 mars 2007 à 21:29, Sébastien Monbrun aka TiChou s'est exprimé
ainsi :
Elle est montée avec quelles options la partition vfat ?
Le umask est sans doute discutable, mais vu que je ne me souviens pas
l'avoir paramétré c'est peut-être un reste de la knoppix initialement
installée.
Tu as essayé avec des noms de fichier ayant le même motif mais sans
être préfixé par AUX ? Genre ABC.HDF.tar.gz ? Ou alors avec d'autres
noms commençant par AUX. ?
Il y a pas mal de noms qui contiennent le motif 'aux' dans le répertoire
et ses enfants (et avec un grand nombre de points). Par exemple :
Ces fichiers sont arrivés par ftp, dans le même lot que le fichier
récalcitrant.
Par ailleurs echo > AUX.HDF.tar.gz échoue, alors que
echo > ABC.HDF.tar.gz fonctionne.
Un point intéressant c'est que echo > AUX.autrefichier échoue également
(argument invalide).
zsh: argument invalide: /mnt/hda3/AUX.HDF.tar.gz
Je suis étonné par le message d'erreur retourné par zsh. Je me serais
plutôt attentu à un message du genre /permission denied/, /no such
file or directory/, etc.
Oui, c'est bizarre. Au fait les derniers essais ont été fait par root.
--
Sébastien Kirche
Le umask est sans doute discutable, mais vu que je ne me souviens pas l'avoir paramétré c'est peut-être un reste de la knoppix initialement installée.
Tu as essayé avec des noms de fichier ayant le même motif mais sans être préfixé par AUX ? Genre ABC.HDF.tar.gz ? Ou alors avec d'autres noms commençant par AUX. ?
Il y a pas mal de noms qui contiennent le motif 'aux' dans le répertoire et ses enfants (et avec un grand nombre de points). Par exemple :
Ces fichiers sont arrivés par ftp, dans le même lot que le fichier récalcitrant.
Par ailleurs echo > AUX.HDF.tar.gz échoue, alors que echo > ABC.HDF.tar.gz fonctionne. Un point intéressant c'est que echo > AUX.autrefichier échoue également (argument invalide).
zsh: argument invalide: /mnt/hda3/AUX.HDF.tar.gz
Je suis étonné par le message d'erreur retourné par zsh. Je me serais plutôt attentu à un message du genre /permission denied/, /no such file or directory/, etc.
Oui, c'est bizarre. Au fait les derniers essais ont été fait par root. -- Sébastien Kirche
