zenreglisse
Ah ! Je vois qu'avec de la patience, tu parviens à récupérer tes données.
Avec «
CCC», oui : tu peux choisir comme "source" un dossier et pas un volume complet.
Voici le procédé le plus commode pour cela :
- Si tu reviens à ta tâche générique de clonage NASTRELLA > NASTRELLA2016 => tu as dû remarquer que «CCC» te propose une fenêtre de menu, sous le carré "source", marquée "Cloner" et indiquant par défaut : "Tous les fichiers" > si tu bascules ce menu à l'option "Fichiers sélectionnés" > tu vois s'afficher, en colonne et par ordre alphabétique du nom des éléments, la liste de tous les éléments enfants de la source (ton volume NASTRELLA), précédés chacun d'une case cochée par défaut.
- Tu peux décocher la 1ère case tout en haut, ce qui désélectionne tous les éléments de la "source" > puis en inspectant l'ordre alphabétique des éléments, sélectionner exclusivement tel dossier non encore recopié qui a ta priorité > represser le bouton "Cloner" - tu vois le topo ?
=> sachant que «
CCC» clone les éléments de la "
source" par
ordre alphabétique d'intitulés des éléments - fichiers et dossiers - contenus, il te sera toujours aisé, après inspection de ton
NASTRELLA2016 de "
destination", de vérifier ce qui te manque encore par ce procédé sélectif. Sinon, en relançant la tâche globale, tous les éléments étant sélectionnés, «
CCC» échappe la recopie des éléments déjà copiés grâce à un protocole de comparaison et ne clone que les éléments pas encore clonés.
--------------------
En ce qui concerne
dd (
data_doubler), il est strictement
impossible de lui assigner comme "
source" un
dossier, pas plus d'ailleurs que comme "
destination". Si jamais tu le fais,
dd termine
illico, en t'affichant la verte admonestation :
"c'est un répertoire !" (autant dire qu'il n'est pas content). Tu ne peux même pas lui donner pour "
source" un
volume, car un volume a, logiquement parlant, un statut équivalent à un répertoire (dossier).
Non. L'utilitaire
dd est programmé pour n'accepter en entrée que des "
containers-disques" ou
devices : soit le container-disque qu'est une
partition, soit le container-disque qu'est une
image-disque (comme un disque virtuel
dmg). Jamais le volume de la partition ou de l'image-disque, qui est comme l'espace-dossier monté du disque.
C'est logique : dès que tu montes l'espace-répertoire d'un volume, tu le fais grâce à un
système de fichiers qui pilote ce montage => à partir de là, tu n'as plus affaire dans l'espace monté de ton dossier-volume qu'à des
fichiers de données (système ou perso), car c'est ainsi qu'un système de fichiers gère l'espace-dossier de montage : par adressage de fichiers de données, lesquels sont des séquences ordonnées d'écritures démarrant à partir d'un bloc où est inscrit le titre du fichier, se déployant sur une série de blocs requise par la taille du fichier, et ayant pour terminaison le bloc sur lequel est inscrit le titre d'un nouveau fichier de donnée.
Mais
dd ne veut rien savoir de tout ça. Pour
dd,
les fichiers n'existent pas. Il ne veut rien avoir à faire avec un système de fichiers qui les gère. Il ne veut pas avoir à faire avec un espace-répertoire monté d'un volume peuplé de fichiers. Non : son plan de compétence est le plan des
containers-disques. C'est-à-dire des périmètres logiques circonscrivant un alignement continu de
blocs de 512 octets chacun. Ce sont donc uniquement les
blocs, avec les constituants granulaires des blocs qui sont les
octets (de
8 bits) que
dd adresse. Peu lui importe que tel bloc supporte l'écriture d'un titre de fichier, ou qu'en passant de tel bloc à tel bloc, il passe de la fin de l'écriture d'un fichiers au titre commençant un nouveau fichier.
La seule chose qui lui importe, ce sont les
alignements numériques de
blocs et l'
intégrité numérique de chaque bloc en terme de nombre de
512 octets de 8 bits.
dd n'exclut jamais aucun
octet ni aucun
bloc, sous prétexte qu'il y a des
bits illisibles : il
patche les bits illisibles, en leur substituant sur la destination leur équivalent en
« null bit », de manière à ne laisser passer
aucun octet dans aucun bloc et à garder un
alignement arithmétique strict de la destination par rapport à la source.
Tu peux demander à
dd d'
échapper ("
skip") tant de blocs à partir du bloc n°1 de départ du container-disque et de ne commencer sa copie qu'à partir du bloc n° tant. Et tu peux demander à dd d'
arrêter sa copie à tel n° de bloc donné. Mais, comme tu le devines > comment savoir que tel dossier de données commence exactement à tel n° de bloc et se termine à tel autre, pour sérier la tâche de
dd ?
=>
En résumé de cet abstrus topo : tiens-toi à «
CCC» et au registre "élevé" des fichiers
(«Tight like this ! » - comme disait Ella Fitzgerald à Louis Armstrong tandis que ce dernier alignait les contre-ut à la trompette).
