Bonjour,
Une question peut-être stupide : lors d’une copie de fichier, que ce soit avec cp (et autre, rsync ?) ou l’interface graphique, a-t-on besoin pour être sûr de contrôler l’intégrité du contenu copié ? Ou tout problème serait-il remonté ?
Merci par avance.
Salut,
AMHA, toute méthode qui n’utilise pas la console peut éventuellement empêcher le système de te signaler un problème. Et dans le copié/collé la main du manipulateur peut avoir dérapé lors du copié 
cp et rsync acceptent des options permettant d’affiner leur comportement. cp ou rsync se lance depuis un terminal ou un script qui comporte un retour d’erreur (-- , 2> , fichier log)
En interface graphique, les options et les retours d’erreur ne sont pas toujours transparents et garantis. Il est donc préférable d’user de la ligne de commande.
Lorsque tu copies des fichiers, compare le système de fichiers de l’original et de la cible.
Une différence de blocs ocupés ou de date s’explique parfois par le système de fichiers de la copie.
Une question récente en support-debian à propos de rsync a soulevé le problème des dates en Fat32.
$ man rsync
--modify-window
When comparing two timestamps, rsync treats the timestamps as being equal if they
differ by no more than the modify-window value. This is normally 0 (for an exact
match), but you may find it useful to set this to a larger value in some situations.
In particular, when transferring to or from an MS Windows FAT filesystem (which rep‐
resents times with a 2-second resolution), --modify-window=1 is useful (allowing
times to differ by up to 1 second).
pour vérifier, tu peut utiliser les fonctions d’hashage comme : sha512sum, md5sum …
mais c’est manuel, je ne sais pas si c’est possible d’integrer ces fonctions avec cp et rsync
Merci à vous et pour votre réactivité.
Je ne vois rien dans les options de cp permettant un contrôle a posteriori.
Je continuerais donc de faire des diff ou des checksums.
[quote=“Zorgluboudou”]Merci à vous et pour votre réactivité.
Je ne vois rien dans les options de cp permettant un contrôle a posteriori.
Je continuerais donc de faire des diff ou des checksums.[/quote]
Tu viens de te répondre à toi-même.
Tu peux aussi comparer le nombre d’octets des fichiers.
Tu spécifies l’option -p comme préserver.
cp se chargera de copier aussi bien qu’il le peut et te signalera son échec éventuel. Certifier n’est pas dans les cordes de cp à l’exception de -u comme update.
Copier et certifier c’est pas pareil.
Imaginons Picasso certifiant des tableaux de Goya et Picasso peignant des copies de Goya.
J’ai la faiblesse de croire que ses certifications seraient prises en moindre considération que ses copies…
Pour répondre à la question de base: oui, théoriquement, il faudrait systématiquement vérifier que la copie est conforme à l’original. Tu n’es pas à l’abri d’un problème matériel (voire logiciel) qui va corrompre les données lors du transfert, malgré tous les dispositifs logiciels mis en place (checksum de paquets .)
Dans la pratique, on vérifie rarement …
Rsync peut utiliser des hash pour définir si le fichier doit être copier, ou non.
Intégrer des hashs dans la copie est, à mes yeux, une idée néfaste.
Que ce soit en local (cp) ou plutôt sur le réseau (rsync), les deux programmes se basent sur des techno qui te garantissent la bonne copie et qui remonte une potentielle erreur.
Sur le réseau, rsync utilise TCP qui te garanti que, lorsqu’il a fini, la source et la destination sont rigoureusement identiques.
En local, les programmes se basent sur le kernel pour copier les fichiers, ce dernier te garanti que les données que tu as copiés sont bien copiés.
Faire des checks via diff ou hash a posteriori, c’est demandé au kernel s’il a fait une erreur.
Tu utilises une fonction pour vérifier que cette même fonction est correcte.
À mon humble avis, jamais il ne va te remonter une erreur.
Merci haleth.
Je ne peux remarquer “rerésolu” mais je prends note.