J'ai un certain nombre de fichiers qui ont été copiés par "cp" (celui
des GNU fileutils) d'un disque vers un répertoire monté via NFS et
certains de ces fichiers sont tronqués (le disque de destination était
plein). Pourtant, cp n'a pas renvoyé de code d'erreur non nul. Y a-t-il
un utilitaire du style cp qui effectuerait une copie et attendrait que
les données soient physiquement écrites sur le disque pour décider de
la valeur de retour?
--
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/> - 100%
validated (X)HTML - Acorn Risc PC, Yellow Pig 17, Championnat International
des Jeux Mathématiques et Logiques, TETRHEX, etc.
Work: CR INRIA - computer arithmetic / SPACES project at LORIA
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
Stephane CHAZELAS
Le Mon, 15 Sep 2003 14:46:18 +0000 (UTC), Vincent Lefevre <vincent+ écrivait :
J'ai un certain nombre de fichiers qui ont été copiés par "cp" (celui des GNU fileutils) d'un disque vers un répertoire monté via NFS et certains de ces fichiers sont tronqués (le disque de destination était plein). Pourtant, cp n'a pas renvoyé de code d'erreur non nul. Y a-t-il un utilitaire du style cp qui effectuerait une copie et attendrait que les données soient physiquement écrites sur le disque pour décider de la valeur de retour?
Je crois que c'est lié à la nature d'NFS. Souvenirs trop vagues, mais certainement une histoire d'optimisation. Ya des chances que la solution la plus simple soit de faire un cksum après copie pour etre bien sur.
[je dis p't'etre des conneries, ça serait pas la première fois voir les specs d'NFS]
-- Stéphane
Le Mon, 15 Sep 2003 14:46:18 +0000 (UTC), Vincent Lefevre <vincent+news@vinc17.org> écrivait :
J'ai un certain nombre de fichiers qui ont été copiés par "cp" (celui
des GNU fileutils) d'un disque vers un répertoire monté via NFS et
certains de ces fichiers sont tronqués (le disque de destination était
plein). Pourtant, cp n'a pas renvoyé de code d'erreur non nul. Y a-t-il
un utilitaire du style cp qui effectuerait une copie et attendrait que
les données soient physiquement écrites sur le disque pour décider de
la valeur de retour?
Je crois que c'est lié à la nature d'NFS. Souvenirs trop vagues,
mais certainement une histoire d'optimisation. Ya des chances
que la solution la plus simple soit de faire un cksum après
copie pour etre bien sur.
[je dis p't'etre des conneries, ça serait pas la première fois
voir les specs d'NFS]
Le Mon, 15 Sep 2003 14:46:18 +0000 (UTC), Vincent Lefevre <vincent+ écrivait :
J'ai un certain nombre de fichiers qui ont été copiés par "cp" (celui des GNU fileutils) d'un disque vers un répertoire monté via NFS et certains de ces fichiers sont tronqués (le disque de destination était plein). Pourtant, cp n'a pas renvoyé de code d'erreur non nul. Y a-t-il un utilitaire du style cp qui effectuerait une copie et attendrait que les données soient physiquement écrites sur le disque pour décider de la valeur de retour?
Je crois que c'est lié à la nature d'NFS. Souvenirs trop vagues, mais certainement une histoire d'optimisation. Ya des chances que la solution la plus simple soit de faire un cksum après copie pour etre bien sur.
[je dis p't'etre des conneries, ça serait pas la première fois voir les specs d'NFS]
-- Stéphane
Vincent Lefevre
Dans l'article , Stephane CHAZELAS écrit:
Le Mon, 15 Sep 2003 14:46:18 +0000 (UTC), Vincent Lefevre <vincent+ écrivait :
J'ai un certain nombre de fichiers qui ont été copiés par "cp" (celui des GNU fileutils) d'un disque vers un répertoire monté via NFS et certains de ces fichiers sont tronqués (le disque de destination était plein). Pourtant, cp n'a pas renvoyé de code d'erreur non nul. Y a-t-il un utilitaire du style cp qui effectuerait une copie et attendrait que les données soient physiquement écrites sur le disque pour décider de la valeur de retour?
Je crois que c'est lié à la nature d'NFS. Souvenirs trop vagues, mais certainement une histoire d'optimisation.
Tout à fait, mais il pourrait y avoir une option...
Ya des chances que la solution la plus simple soit de faire un cksum après copie pour etre bien sur.
À condition que le checksum ne soit pas lu dans le cache NFS! Et puis le fichier source peut avoir changé entre temps, ce qui alourdit les choses (il faudrait passer par un fichier temporaire).
-- Vincent Lefèvre - Web: <http://www.vinc17.org/> - 100% validated (X)HTML - Acorn Risc PC, Yellow Pig 17, Championnat International des Jeux Mathématiques et Logiques, TETRHEX, etc. Work: CR INRIA - computer arithmetic / SPACES project at LORIA
Dans l'article <slrnbmbmio.40.stephane_chazelas@pcchazelas.free.fr>,
Stephane CHAZELAS <stephane_chazelas@yahoo.fr> écrit:
Le Mon, 15 Sep 2003 14:46:18 +0000 (UTC), Vincent Lefevre
<vincent+news@vinc17.org> écrivait :
J'ai un certain nombre de fichiers qui ont été copiés par "cp" (celui
des GNU fileutils) d'un disque vers un répertoire monté via NFS et
certains de ces fichiers sont tronqués (le disque de destination était
plein). Pourtant, cp n'a pas renvoyé de code d'erreur non nul. Y a-t-il
un utilitaire du style cp qui effectuerait une copie et attendrait que
les données soient physiquement écrites sur le disque pour décider de
la valeur de retour?
Je crois que c'est lié à la nature d'NFS. Souvenirs trop vagues,
mais certainement une histoire d'optimisation.
Tout à fait, mais il pourrait y avoir une option...
Ya des chances que la solution la plus simple soit de faire un cksum
après copie pour etre bien sur.
À condition que le checksum ne soit pas lu dans le cache NFS! Et puis
le fichier source peut avoir changé entre temps, ce qui alourdit les
choses (il faudrait passer par un fichier temporaire).
--
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/> - 100%
validated (X)HTML - Acorn Risc PC, Yellow Pig 17, Championnat International
des Jeux Mathématiques et Logiques, TETRHEX, etc.
Work: CR INRIA - computer arithmetic / SPACES project at LORIA
Le Mon, 15 Sep 2003 14:46:18 +0000 (UTC), Vincent Lefevre <vincent+ écrivait :
J'ai un certain nombre de fichiers qui ont été copiés par "cp" (celui des GNU fileutils) d'un disque vers un répertoire monté via NFS et certains de ces fichiers sont tronqués (le disque de destination était plein). Pourtant, cp n'a pas renvoyé de code d'erreur non nul. Y a-t-il un utilitaire du style cp qui effectuerait une copie et attendrait que les données soient physiquement écrites sur le disque pour décider de la valeur de retour?
Je crois que c'est lié à la nature d'NFS. Souvenirs trop vagues, mais certainement une histoire d'optimisation.
Tout à fait, mais il pourrait y avoir une option...
Ya des chances que la solution la plus simple soit de faire un cksum après copie pour etre bien sur.
À condition que le checksum ne soit pas lu dans le cache NFS! Et puis le fichier source peut avoir changé entre temps, ce qui alourdit les choses (il faudrait passer par un fichier temporaire).
-- Vincent Lefèvre - Web: <http://www.vinc17.org/> - 100% validated (X)HTML - Acorn Risc PC, Yellow Pig 17, Championnat International des Jeux Mathématiques et Logiques, TETRHEX, etc. Work: CR INRIA - computer arithmetic / SPACES project at LORIA
Pascal Bourguignon
Stephane CHAZELAS writes:
Le Mon, 15 Sep 2003 14:46:18 +0000 (UTC), Vincent Lefevre <vincent+ écrivait :
J'ai un certain nombre de fichiers qui ont été copiés par "cp" (celui des GNU fileutils) d'un disque vers un répertoire monté via NFS et certains de ces fichiers sont tronqués (le disque de destination était plein). Pourtant, cp n'a pas renvoyé de code d'erreur non nul. Y a-t-il un utilitaire du style cp qui effectuerait une copie et attendrait que les données soient physiquement écrites sur le disque pour décider de la valeur de retour?
Je crois que c'est lié à la nature d'NFS. Souvenirs trop vagues, mais certainement une histoire d'optimisation. Ya des chances que la solution la plus simple soit de faire un cksum après copie pour etre bien sur.
[je dis p't'etre des conneries, ça serait pas la première fois voir les specs d'NFS]
- ftp : ça marche toujours au poil.
- tar/ssh : tar -C $source -cf - | ssh $user@$remote tar -C $dest -xf -
Selon le type de fichiers, la puissance des machines et la bande passante disponible entre elles, on a intérêt ou non à compresser, et ça peut se faire soit au niveau des tar (ajoutant -z ou -j), ou au niveau de ssh (ajoutant un -C).
- rsync : mais personnellement, j'ai pas trouvé qu'il marche bien; souvent, il termine avec les trois processus en 'S' et un signal de fin d'I/O perdu.
-- __Pascal_Bourguignon__ http://www.informatimago.com/ Do not adjust your mind, there is a fault in reality.
Le Mon, 15 Sep 2003 14:46:18 +0000 (UTC), Vincent Lefevre <vincent+news@vinc17.org> écrivait :
J'ai un certain nombre de fichiers qui ont été copiés par "cp" (celui
des GNU fileutils) d'un disque vers un répertoire monté via NFS et
certains de ces fichiers sont tronqués (le disque de destination était
plein). Pourtant, cp n'a pas renvoyé de code d'erreur non nul. Y a-t-il
un utilitaire du style cp qui effectuerait une copie et attendrait que
les données soient physiquement écrites sur le disque pour décider de
la valeur de retour?
Je crois que c'est lié à la nature d'NFS. Souvenirs trop vagues,
mais certainement une histoire d'optimisation. Ya des chances
que la solution la plus simple soit de faire un cksum après
copie pour etre bien sur.
[je dis p't'etre des conneries, ça serait pas la première fois
voir les specs d'NFS]
- ftp : ça marche toujours au poil.
- tar/ssh : tar -C $source -cf - | ssh $user@$remote tar -C $dest -xf -
Selon le type de fichiers, la puissance des machines et la bande
passante disponible entre elles, on a intérêt ou non à compresser, et
ça peut se faire soit au niveau des tar (ajoutant -z ou -j), ou au
niveau de ssh (ajoutant un -C).
- rsync : mais personnellement, j'ai pas trouvé qu'il marche bien;
souvent, il termine avec les trois processus en 'S' et un signal de
fin d'I/O perdu.
--
__Pascal_Bourguignon__
http://www.informatimago.com/
Do not adjust your mind, there is a fault in reality.
Le Mon, 15 Sep 2003 14:46:18 +0000 (UTC), Vincent Lefevre <vincent+ écrivait :
J'ai un certain nombre de fichiers qui ont été copiés par "cp" (celui des GNU fileutils) d'un disque vers un répertoire monté via NFS et certains de ces fichiers sont tronqués (le disque de destination était plein). Pourtant, cp n'a pas renvoyé de code d'erreur non nul. Y a-t-il un utilitaire du style cp qui effectuerait une copie et attendrait que les données soient physiquement écrites sur le disque pour décider de la valeur de retour?
Je crois que c'est lié à la nature d'NFS. Souvenirs trop vagues, mais certainement une histoire d'optimisation. Ya des chances que la solution la plus simple soit de faire un cksum après copie pour etre bien sur.
[je dis p't'etre des conneries, ça serait pas la première fois voir les specs d'NFS]
- ftp : ça marche toujours au poil.
- tar/ssh : tar -C $source -cf - | ssh $user@$remote tar -C $dest -xf -
Selon le type de fichiers, la puissance des machines et la bande passante disponible entre elles, on a intérêt ou non à compresser, et ça peut se faire soit au niveau des tar (ajoutant -z ou -j), ou au niveau de ssh (ajoutant un -C).
- rsync : mais personnellement, j'ai pas trouvé qu'il marche bien; souvent, il termine avec les trois processus en 'S' et un signal de fin d'I/O perdu.
-- __Pascal_Bourguignon__ http://www.informatimago.com/ Do not adjust your mind, there is a fault in reality.
Vincent Lefevre
Dans l'article , Pascal Bourguignon écrit:
- ftp : ça marche toujours au poil.
Impossible, car non automatique (je n'ai pas envie de laisser mon password traîner...), mais:
- tar/ssh : tar -C $source -cf - | ssh $user@$remote tar -C $dest -xf -
Ceci dit, je ne vois pas en quoi ça résout le problème: on change de machine, mais l'accès se fait toujours par NFS, d'où les mêmes problèmes (le répertoire n'est accessible que par NFS).
- rsync : mais personnellement, j'ai pas trouvé qu'il marche bien; souvent, il termine avec les trois processus en 'S' et un signal de fin d'I/O perdu.
Idem.
-- Vincent Lefèvre - Web: <http://www.vinc17.org/> - 100% validated (X)HTML - Acorn Risc PC, Yellow Pig 17, Championnat International des Jeux Mathématiques et Logiques, TETRHEX, etc. Work: CR INRIA - computer arithmetic / SPACES project at LORIA
Dans l'article <87oexluddk.fsf@thalassa.informatimago.com>,
Pascal Bourguignon <spam@thalassa.informatimago.com> écrit:
- ftp : ça marche toujours au poil.
Impossible, car non automatique (je n'ai pas envie de laisser mon
password traîner...), mais:
- tar/ssh : tar -C $source -cf - | ssh $user@$remote tar -C $dest -xf -
Ceci dit, je ne vois pas en quoi ça résout le problème: on change
de machine, mais l'accès se fait toujours par NFS, d'où les mêmes
problèmes (le répertoire n'est accessible que par NFS).
- rsync : mais personnellement, j'ai pas trouvé qu'il marche bien;
souvent, il termine avec les trois processus en 'S' et un signal de
fin d'I/O perdu.
Idem.
--
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/> - 100%
validated (X)HTML - Acorn Risc PC, Yellow Pig 17, Championnat International
des Jeux Mathématiques et Logiques, TETRHEX, etc.
Work: CR INRIA - computer arithmetic / SPACES project at LORIA
Impossible, car non automatique (je n'ai pas envie de laisser mon password traîner...), mais:
- tar/ssh : tar -C $source -cf - | ssh $user@$remote tar -C $dest -xf -
Ceci dit, je ne vois pas en quoi ça résout le problème: on change de machine, mais l'accès se fait toujours par NFS, d'où les mêmes problèmes (le répertoire n'est accessible que par NFS).
- rsync : mais personnellement, j'ai pas trouvé qu'il marche bien; souvent, il termine avec les trois processus en 'S' et un signal de fin d'I/O perdu.
Idem.
-- Vincent Lefèvre - Web: <http://www.vinc17.org/> - 100% validated (X)HTML - Acorn Risc PC, Yellow Pig 17, Championnat International des Jeux Mathématiques et Logiques, TETRHEX, etc. Work: CR INRIA - computer arithmetic / SPACES project at LORIA
