je me dis que le DDE a un problème, qui ne se limite pas à une corruption de système de fichiers d'une partition (puisque celui de la partition
Sans titre passe la vérification d'intégrité, apparemment). Et que ça présage l'abandon du challenger
macO, incapable de percer la garde du tenant, paradoxalement nommé
Sans titre...
Pour ce qui est d'un utilitaire de copie fichier à fichier (impliquant le système de fichiers monté du volume
Sans titre pour ce faire) échappant les données invalidées par des blocs illisibles, je pense que c'est ce qu'ils font par défaut (par exemple,
rsync sait très bien écarter les fichiers qu'il ne peut pas lire, en décrétant :
input/output error et en passant aux suivants). Mais le problème, c'est ce que ces utilitaires ou logiciels (comme «
CCC») établissent en préalable une liste de la série complète des fichiers lisibles à recopier, avant d'en traiter les éléments terme à terme - or, d'après les retours de
Robin avec
rsync et «
CCC», il y a échec d'entrée à dresser une telle liste. Ce qui me laisse conjecturer qu'aucun fichier n'est reconnu a priori lisible (càd. exempt de blocs indéchiffrables).
Le bizarre c'est qu'un logiciel comme «
iTunes» a l'air de pouvoir « jouer » ces fichiers, alors que les cloneurs n'arrivent pas à y voir des fichiers « lisibles ». Est-ce à dire que les critères de « lisibilité » sont plus drastiques pour les utilitaires de copie ? - Je suis un peu réduit
à quia, ici, parce que je n'ai rien d'un spécialiste informaticien sur ces questions (ni sur aucune autre, d'ailleurs).
--------------------
J'ai toujours des réticences à préconiser le recours à l'utilitaire
dd (
data_doubler). Certes, c'est un outil susceptible de passer à travers le problème des "fichiers illisibles", car il ne copie pas des fichiers. Il ne copie même pas en bloc à bloc comme
asr (ce qui implique que les blocs soient lisibles) > il recrée les alignements de blocs de 512 octets à partir des octets, en étant capable de remplacer (si on lui en donne l'option) tout bit indéchiffrable dans un octet par un
« null bit » de manière à ne jamais échapper le moindre composant des octets, et par là-même à être capable de créer sur la destination des séries de blocs de 512 octets parfaitement alignés en écho de ceux de la source.
Mais cette puissance élémentaire («
chtonienne » et pas «
ouranienne ») se solde par une extraordinaire lenteur des opérations. Dans mon expérience, de tous les utilitaires de clonage fournis nativement dans
OS X >
dd est le plus lent et de loin. Dès qu'il est question sur la "source" de
n Go de données, cette lenteur devient vertigineuse. Dans un fil épique : ☞
Problème carte SD☜, où la taille de la carte était de 32 Go et celle des données de 8 Go > le processus
dd tournait à
2,5 Go par tranche de 12 heures, soit
5 Go par jour ! Malgré de lancinantes déclarations d'
input / output error (signalant que
dd patchait des bits illisibles), jamais
dd n'a été bloqué dans son opération pour autant et à la fin toutes les données ont pu être récupérées comme fichiers ouvrables et lisibles. Mais au prix de quelle lenteur :
un jour et demi d'opération en continue 24/24 heures pour récupérer
8 Go.
Dans un autre fil où la taille des données de la "source" à récupérer était fantastique (
976 Go) : ☞
DDE en FAT-32 en lecture seule☜ >
dd, tout en alignant monotonement les alertes d'
input / output error, paraissait opérer à une vitesse de
4 Go par heure, laissant présager un délai de complétion de
10 jours environ (à condition de fonctionner en continu 24/24 heures). On notera que le processus
dd ne bloquait pas malgré les erreurs rencontrées (mais arrivait à les « patcher », alors que la moindre erreur pour un cloneur de fichier invalide
ipso facto la donnée complète qui est échappée). De surcroît, en sus de sa phénoménale lenteur exécutive, le problème de
dd est son fonctionnement mutique (il n'y a jamais d'affichage d'une progression - rien que des déclarations éventuelles d'
input / output error). L'intéressant quand même est de noter que sa vitesse d'opération était très supérieure avec un DDE en "
source" par rapport au cas de figure de la carte SD, ce qui montre que le type de périphérique et de connexion influe directement sur la vitesse des opérations =>
96 Go / jour pour
zenreglisse (DDE) vs
5 Go / jour pour
Krystoff (carte SD), soit
19 fois plus vite.
Donc, si l'on est sûr avec
dd que ça va être une épreuve de patience (et une initiation au
Stoïcisme) > on ne peut jamais prévoir une vitesse par défaut : on découvre l'état des lieux après avoir commencé...
--------------------
Par suite,
Robin, si tu veux (malgré mes avertissements décourageants) faire un essai avec
dd > il faudrait que tu me fournisses plusieurs informations (je connais déjà la taille en données de la source : 176 Go, ce qui permet de fixer d'emblée à l'opération
dd une limite de quantité de blocs à ne pas dépasser) :
- a) l'identifiant logique de device de la partition Sans titre. Pour ce faire, tu attaches ce DDE à ton Mac et dans le «
Terminal» tu passes la commande (informative) :
et tu fais un copier-coller ici du tableau des disques et des partitions retourné. Car
dd (à l'exact inverse d'
asr) ne veut pas du tout d'une source adressée par un
point de montage (donc un volume) ; mais d'une source adressée par le
conteneur-disque de la partition (donc un identifiant de
device).
- b) où tu veux que soit localisée la destination de l'opération : le volume alternatif de
Sans titre que tu as créé sur le disque de ton DDE ? Le répertoire
Musique de ton compte dans le volume
Anonymous du SSD de ton Mac (ce qui implique que tu aies 200 Go de place libre dans le volume de ce SSD) ?
- c) si tu utilises le Mac concerné uniquement en mode "Desktop" (bécane de bureau fixe - même si c'est un portable) ? Ou si tu trimbales ton Mac en
mode nomade ? Parce que le processus
dd lancé pour 176 Go à récupérer implique une série de jours où le Mac ne doit pas être éteint, ni l'application «
Terminal» fermée (si l'on veut arriver à complétion) - même s'il est possible de suspendre la tâche
dd en la gardant en mémoire, ce qui permet de détacher le DDE pendant des laps de temps. Il est très possible que tes conditions d'emploi de ton Mac (si c'est un portable) proscrivent une astreignante exécution d'un processus
dd jusqu'à complétion.
--------------------