Est-il préférable d'utiliser cat, dd, pv ou une autre procédure pour copier un CD/DVD ?

Toutes les commandes suivantes sont équivalentes. Ils lisent les octets du CD /dev/sr0 et écrivez-les dans un fichier appelé image.iso .

cat /dev/sr0 >image.iso
cat </dev/sr0 >image.iso
tee </dev/sr0 >image.iso
dd </dev/sr0 >image.iso
dd if=/dev/cdrom of=image.iso
pv </dev/sr0 >image.iso
cp /dev/sr0 image.iso
tail -c +1 /dev/sr0 >image.iso

Pourquoi utiliseriez-vous l'un plutôt que l'autre ?

Simplicité. Par exemple, si vous connaissez déjà cat ou cp , vous n'avez pas besoin d'apprendre une autre commande.
Robustesse. Celui-ci est un peu une variante de la simplicité. Quel est le risque que la modification de la commande modifie ce qu'elle fait ? Voyons quelques exemples :
- Tout ce qui comporte une redirection :vous pouvez accidentellement mettre une redirection dans le mauvais sens, ou l'oublier. Puisque la destination est censée être un fichier inexistant, set -o noclobber doit s'assurer que vous n'écrasez rien ; cependant, vous pouvez écraser un périphérique si vous écrivez accidentellement >/dev/sda (pour un CD, qui est en lecture seule, il n'y a aucun risque, bien sûr). Cela plaide en faveur de cat /dev/sr0 >image.iso (difficile de se tromper de manière préjudiciable) par rapport à des alternatives telles que tee </dev/sr0 >image.iso (si vous inversez les redirections ou oubliez celle d'entrée, tee écrira à /dev/sr0 ).
- cat :vous pouvez accidentellement concaténer deux fichiers. Cela laisse les données facilement récupérables.
- dd :i et o sont proches sur le clavier, et quelque peu inhabituelles. Il n'y a pas d'équivalent de noclobber , of= se fera un plaisir d'écraser n'importe quoi. La syntaxe de redirection est moins sujette aux erreurs.
- cp :si vous permutez accidentellement la source et la cible, le périphérique sera écrasé (encore une fois, en supposant un périphérique non en lecture seule). Si cp est invoqué avec certaines options telles que -R ou -a que certaines personnes ajoutent via un alias, il copiera le nœud de l'appareil plutôt que le contenu de l'appareil.
Fonctionnalité supplémentaire. Le seul outil ici qui a des fonctionnalités supplémentaires utiles est pv , avec ses puissantes options de création de rapports.
Mais ici, vous pouvez vérifier combien a été copié en regardant quand même la taille du fichier de sortie.
Performance. Il s'agit d'un processus lié aux E/S; la principale influence sur les performances est la taille de la mémoire tampon :l'outil lit un bloc à partir de la source, écrit le bloc dans la destination, répète. Si le morceau est trop petit, l'ordinateur passe son temps à basculer entre les tâches. Si le morceau est trop grand, les opérations de lecture et d'écriture ne peuvent pas être parallélisées. La taille de bloc optimale sur un PC est généralement d'environ quelques mégaoctets, mais cela dépend évidemment beaucoup du système d'exploitation, du matériel et de ce que l'ordinateur fait d'autre. J'ai fait des tests de performances pour les copies de disque dur à disque dur il y a quelque temps, sous Linux, qui ont montré que pour les copies sur le même disque, dd avec une grande taille de tampon a l'avantage, mais pour les copies interdisques, cat a conquis n'importe quel dd taille du tampon.

Il y a plusieurs raisons pour lesquelles vous trouvez dd mentionné si souvent. En dehors des performances, ce ne sont pas des raisons particulièrement bonnes.

Dans les très anciens systèmes Unix, certains outils de traitement de texte ne pouvaient pas gérer les données binaires (ils utilisaient des chaînes à terminaison nulle en interne, ils avaient donc tendance à avoir des problèmes avec les octets nuls ; certains outils supposaient également que les caractères n'utilisaient que 7 bits et n'a pas traité correctement les jeux de caractères 8 bits). Je ne sais pas si cela a déjà été un problème avec cat (c'était avec des outils plus orientés ligne tels que head , sed , etc.), mais les gens avaient tendance à l'éviter sur les données binaires en raison de son association avec le traitement de texte. Ce n'est pas un problème sur les systèmes modernes tels que Linux, OSX, *BSD ou tout ce qui est compatible POSIX.
Il existe une sorte de mythe selon lequel dd est quelque peu "de niveau inférieur" à d'autres outils tels que cat et accède directement aux appareils. C'est complètement faux :dd et cat et tee et les autres lisent tous les octets de leur entrée et écrivent les octets sur leur sortie. La vraie magie est dans /dev/sr0 .
dd a une syntaxe de ligne de commande inhabituelle, donc expliquer comment cela fonctionne donne plus d'opportunités de briller en expliquant quelque chose qui écrit simplement cat /dev/sr0 .
Utiliser dd avec une grande taille de tampon peut avoir de meilleures performances, mais ce n'est pas toujours le cas (voir quelques benchmarks sur Linux).

Un risque majeur avec dd est que il peut ignorer silencieusement certaines données . Je pense dd est sûr tant que skip ou count ne sont pas passés mais je ne sais pas si c'est le cas sur toutes les plateformes. Mais il n'a d'autre avantage que les performances.

Alors utilisez simplement pv si vous voulez son rapport d'avancement fantaisiste, ou cat si vous ne le faites pas.

Au lieu d'utiliser des outils génériques comme cat ou dd , il faut préférer des outils plus fiables sur les erreurs de lecture comme

drescue
readcd (qui intègre des mécanismes de corrections d'erreurs/de nouvelles tentatives pour les lecteurs de CD/DVD)

De plus, leurs paramètres par défaut sont plus appropriés que par ex. dd s.

Il y a des faits intéressants dans ce cas, spécialement ceux-ci :

Je viens de vérifier la sortie que j'ai reçue et fournie (j'ai utilisé un autre disque cette fois, exactement, le disque d'installation Xubuntu 15.04 x64), et avec les deux procédures (dd et pv ) les sommes de contrôle sont identiques .
J'ai eu l'idée, après avoir fait le dd procédure, ouvrez le lecteur et fermez-le avec le même disque, puis terminez le test avec le pv procédure. En faisant cela, j'ai obtenu des copies identiques avec les deux procédures.
Je pense J'ai obtenu différentes sommes de contrôle la première fois, car pour une raison quelconque, les données collectées à partir du lecteur de CD/DVD semblent être "enregistrées" à d'autres fins pendant un certain temps (comme un cache) -- ainsi, d'autres opérations comme les sommes de contrôle ont été faites beaucoup plus rapide que le transfert. Veuillez commenter si vous connaissez la cause exacte de cela.
Un autre fait est que dd sans le count=X le paramètre s'arrête correctement à la fin du disque et donne la même image disque qu'avec pv (les sommes de contrôle sont identiques), il est donc préférable pour moi d'utiliser dd sans paramètres ou juste pv .

Donc, pour l'instant, il semble pv et dd peut accomplir une copie de CD/DVD avec les mêmes résultats.