10.11 El Capitan CODE ERREUR -36

Bonsoir à vous, j'ai des nouvelles du front.

J'ai tenté un diskwarrior (j'ai acheté le 4 il y a quelques années), mais ça n'a rien donné malheureusement, il m'affiche le disque comme valide.

@macomaniac , j'ai fait ta manip avec le terminal et voilà le résultat :


Anonymous:~ Anonymous$ hdiutil create -type SPARSE -size 1t -fs jhfs+ -volname CIBLE Desktop/BACKUP.sparseimage -attach

/dev/disk3 GUID_partition_scheme

/dev/disk3s1 EFI

/dev/disk3s2 Apple_HFS /Volumes/CIBLE

created: /Users/Anonymous/Desktop/BACKUP.sparseimage

Anonymous:~ Anonymous$ sudo asr restore -s /Volumes/Sans\ titre -t /Volumes/CIBLE -erase -noprompt

Password:

Validating target...done

Validating source...done

Source volume is read-write and cannot be unmounted, so it can't be block copied.
 
Bloc de code:
Validating target...done
Validating source...done
Source volume is read-write and cannot be unmounted, so it can't be block copied.

Allons bon ! Voici comment j'interprète ces messages =>

- au positif : le volume cible a été validé en taille et en format (jhfs+) > le volume source a été pareillement validé (on en déduit que son format est lui aussi jhfs+, asr rejetant tout autre format de système de fichiers).

- au négatif : pour engager le clonage bloc à bloc, asr a besoin de démonter le système de fichiers qui est monté en lecture / écriture. Or il ne parvient pas à effectuer ce démontage, et donc ne peut pas engager son opération de copie.
=> cela me paraît confirmer que le système de fichiers de ton volume Sans titre est corrompu, ce qui empêche asr de le manipuler.

Est-ce que tu as tenté une réparation de ce système de fichiers ? Ton DDE attacé à ton Mac > lance l'«Utilitaire de Disque» d'«El Capitan» > sélectionne le volume Sans titre dans la colonne de gauche > presse le bouton S.O.S. => Des erreurs sont-elles mentionnées en cours de vérification ? Marquées réparées ? Quel est le résultat final : « le volume Sans titre semble être en bon état » ou le contraire ?

Si tu obtenais après des réparations un résultat satisfaisant > assure-toi que le volume CIBLE de ton image-disque (si tu l'as gardée) BACKUP.sparseimage est bien monté (double-clic sur l'image-disque s'il faut - si tu as jeté l'image-disque, repasse la 1ère commande qui la recrée et remonte le volume CIBLE) > repasse alors la 2è commande = asr et vois ce qu'il en ressort : l'utilitaire échoue-t-il toujours à démonter le système de fichiers  pour engager sa copie ?

--------------------
Quoi qu'il en soit des opérations ci-dessus, peux-tu par ailleurs me dire combien de Go exactement pèse ton dossier Music contenu dans le volume Sans titre (bref la taille des données actuelles contenues dans ce dossier) ? Ouvre une fenêtre d'info du Finder par ⌘I sur le dossier Music et regarde quelle est la taille indiquée --> ce serait pour construire une autre commande, appelant un autre utilitaire à la rescousse (pour lui indiquer combien de Go il doit cloner dans le volume Sans titre et à quelle limite s'arrêter)...
 
J'ai tenté une réparation mais l'utilitaire de disque m'affirme que le DDE est en très bon état et il ne trouve aucune erreur à corriger.

Par ailleurs, le dossier music fait exactement 176 691 434 444 octets (176,73 Go sur disque) pour 24 314 éléments.

Il y a quelque chose que je n'arrive pas à comprendre, l'image présente sur mon bureau "BACKUP.sparseimage" fait 688mo, est-ce normal ? Cela veux bien dire qu'il n'a pas réussi à aller plus loin, d'où l'erreur du terminal (si je comprend bien).

Je suis OP pour essayer une nouvelle commande :)
 
Si le système de fichiers de ton volume Sans titre passe la vérification d'intégrité > je ne comprends pas du tout pourquoi asr plante à le démonter. Et le problème, c'est qu'on ne peut pas le lui démonter au préalable, parce qu'asr requiert une "source" définie au départ par un point de montage (c'est-à-dire un système de fichiers monté en volume), et pareil d'ailleurs pour la "destination", et c'est lui-même qui revendique de démonter à sa convenance ces systèmes de fichiers. Les démonter à l'avance (via l'«Utilitaire de Disque» ou le «Terminal»), c'est ôter à asr toute possibilité d'adresser la "source" et la "destination".

Bref : dans ton cas de figure > je ne vois pas du tout quoi faire pour qu'asr accepte d'opérer, car je ne vois pas du tout ce qui le bloque à démonter le système de fichiers de la "source", si ce ne sont pas des erreurs intrinsèques.

--------------------​

À présent : je ne pensais pas que ton dossier Music avait une telle importance : 176 Go ! C'est énorme.

Ce poids imposant est problématique sous 3 aspects :

- a) d'abord, as-tu suffisamment d'espace libre dans le volume de ton OS Anonymous pour accueillir 176 Go de données (à supposer que le transfert puisse s'opérer) ? Si oui, ce n'est certainement pas ton Bureau qu'il faut envisager comme destination, car ce serait la meilleure façon de planter le Finder, qui n'apprécie pas du tout de gérer un dossier Desktop trop chargé.

- b) ensuite, 176 Go de données à copier impliquent, avec l'utilitaire dd (data_doubler) auquel je pensais, un temps très très long d'opération. D'une part, parce que dd copie octet à octet en reconstruisant méthodiquement avec des blocs de 512 octets, ce qui est un processus intrinsèquement lent ; d'autre part, parce que cette lenteur intrinsèque est sensible au type de connexion "source" > "destination" --> si le DDE dont dépend ton volume Sans titre ("source") est attaché au Mac en USB-2, il est clair que l'opération dd sera interminable. D'autant plus si le disque interne de ton Mac est un HDD. Ça peut prendre des jours et des jours...

- c) enfin, le fonctionnement de dd ne supporte pas le mode "verbose" : c'est-à-dire l'affichage ligne à ligne de l'exécution de copie de fichiers. La raison en est simple : dd ne copie pas de fichiers. À la rigueur, on aurait pu espérer l'affichage d'un % de progression : tel n'est pas le cas. Ce caractère mutique du processus fait que, tant que l'invite de commande dans la fenêtre du «Terminal» n'est pas ré-affichée, il faut attendre en aveugle que dd effectue son travail de coulisse.​

--------------------​

Étant donné ces problèmes qui se composent, je te suggère plutôt de faire une tentative intermédiaire sans recourir à dd (renvoyé à la fonction d'outil de la dernière chance) > en passant par le logiciel de clonage ☞Carbon Copy Cloner☜ (clique sur le lien pour avoir l'adresse de son téléchargement. Tu peux l'utiliser en démo gratuitement un mois sans limitation fonctionnelle).

Avant de lancer la tâche de «CCC», il convient que tu choisisses soigneusement une localisation idoine de "destination". Tu as 2 possibilités :

- a) si tu as de la place libre sur le disque de ton DDE, tu peux le repartitionner dans l'«Utilitaire de Disque» pour exporter un 2è volume, intitulé par exemple RECUP, de 200 Go > opération qui se fera sans porter préjudice à ton volume initial Sans titre, dont le dossier Music sera préservé, mais dont la taille globale de partition sera rétrécie. Il faudrait pour ce faire que le disque de ce DDE fasse 500 Go.

- b) si tu préfères une localisation sur le disque de ton Mac, il faut avant tout que tu aies disons 200 Go là encore d'espace libre dans le volume Anonymous de ton OS. Si c'est le cas, alors il faut que tu crées un dossier de "destination" pour les fichiers de ta "source" (= Music), parce que «CCC», si on lui donne pour "source" un dossier (et pas un volume), ne recopie pas le dossier parent à l'emplacement de destination, mais seulement les fichiers enfants (attention à l'inondation si on n'a pas créé un dossier d'accueil...).

Donc il faudrait dans ce cas de figure que tu crées un dossier vide intitulé genre MUSIC-BACKUP dans un emplacement judicieusement choisi : pas ton Bureau, vu le poids des données ! Plutôt dans le répertoire Musique de ton compte.​

=> une fois que tu as choisi ton type de destination (volume RECUP ou dossier MUSIC-BACKUP), tu lances «CCC», tu presses le bouton + pour créer une nouvelle tâche et tu choisis une des 2 options suivantes :

- a) clonage de volume à volume : tu fais un glisser-déposer de l'icône de ton volume monté Sans titre sur le carré de la "source" > tu fais un glisser-déposer de l'icône du volume monté RECUP sur le carré de la "destination" --> tu désactives l'option "Safety Net" et tu presses le bouton "Cloner".

- b) clonage de dossier à dossier : tu fais glisser le dossier Music (contenu dans ton volume Sans titre) sur le carré de la "source" > tu fais glisser le dossier vide MUSIC-BACKUP (contenu dans le dossier Musique de ton compte) sur le carré de la "destination" --> tu désactives l'option "Safety Net" et tu presses le bouton "Cloner".​

=> tu vas bien voir... ce que tu vas voir (si «CCC» copie quelque chose plutôt que rien). À quelle vitesse... Sachant que tu peux arrêter la tâche de «CCC». Qui en conservera la définition : en redémarrant le logiciel, rechoisissant la tâche et la relançant > «CCC» revérifie en mode express les données déjà copiées puis reprend au point quitté du clonage.

--------------------​
 
Dernière édition par un modérateur:
Hello @macomaniac ,

Petite précision, mon disque dur interne est un SSD, il n'est donc pas si lent que ça.

J'ai essayé de lancer CCC avec une copie dossier vers dossier, j'ai eu le message d'erreur suivant :
"Ces erreurs indiquent que ce disque rencontre un problème (panne de média, panne mécanique, erreur dans le programme interne du disque, problème de communication avec le disque, etc.). Le degré de sévérité du problème est inconnu. Pour obtenir plus de détails sur ces erreurs, cliquez sur le volume concerné dans la barre latérale de CCC. Les statistiques d’erreur de lecture/écriture seront réinitialisées au redémarrage de l’ordinateur."

Je vais donc essayer une copie volume par volume.
 
Malheureusement je n'ai pas réussi à faire une copie bloc par bloc avec CCC.

Là la copie se fait fichier par fichier et il bug toujours sur le même fichier (avec un temps de traitement interminable par fichier).
 
Il faudrait une commande copiant fichier par fichier et sautant au suivant quand elle tombe sur un fichier dont une partie est illisible.

Ca permettrait de sauver tous les fichiers qui sont encore lisibles...

MacO, tu n'as pas ca en magasin?
 
je n'ai pas réussi à faire une copie bloc par bloc avec CCC.
Et pour cause : «CCC» copie fichier à fichier, pas bloc à bloc. C'est donc un cloneur de type rsync. Mais comme son développeur, Mike Bombich, n'arrête pas de raffiner son outil > l'occasion était belle de voir ce qu'il pouvait donner.​

Mais quand je lis le message de déboguage après le premier échec de «CCC» :
Mike Bombich a dit:
"Ces erreurs indiquent que ce disque rencontre un problème (panne de média, panne mécanique, erreur dans le programme interne du disque, problème de communication avec le disque, etc.). Le degré de sévérité du problème est inconnu."
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...
361608_original.png


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) :
Bloc de code:
diskutil list
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.​
--------------------​
 
Dernière édition par un modérateur:
Ce disque semble bien mal en point, physiquement parlant...
Il va falloir penser à sortir la copie de sauvegarde de ces musiques, je pense.
 
Bonsoir à vous deux,

Merci de vous donner tant de mal et d'éclairer ma lanterne ainsi.

Je pense que je vais lancer la manipulation dont tu parles @macomaniac , cependant, grace au clone de mon disque, j'ai pu voir quels fichiers posaient problème. Je vais essayer de les isoler des autres afin de pouvoir lancer l'opération sur ces éléments là uniquement.

En fait grâce à la première commande que j'avais rentré dans le terminal, j'ai pû copier la liste des éléments transférés dans un document word. Là je viens de faire la recherche dans le document avec la mention " Input/output" (liée à l'erreur) et il semble qu'il y en aurait 240. Soit 240 fichiers musicaux "corrompus". Maintenant je vais tenter de les isoler. Je pense que ça va prendre un certain temps...

A moins que vous ayez une ligne de code pour ça ?
 
Dernière édition:
Hé ! hé ! je vois que l'ingéniosité de ne fait pas défaut :up:

Tu n'as qu'à créer, dans ton volume Sans titre, un dossier intitulé QUARANTAINE en-dehors du dossier existant Music, et faire l'essai d'y déplacer tes 240 fichiers corrompus, stigmatisés par la marque d'infamie : Input / output error dans ta liste. Peut-être que cette opération manuelle, à l'intérieur de l'espace du volume Sans titre, d'un dossier y recelé à un autre vicinal, est-elle facilement supportée. Fais l'essai sur un des fichiers incriminés.

Au cas où ça marcherait sur un fichier, j'ai peur de ne pas avoir sous la main de procédé pour automatiser le déplacement des 240, car le label « Input / output error » ne fait pas partie du titre de ces fichiers, mais est une attestation d'échec sanctionnant une tentative de copie sur un autre disque. Il faudrait un script commandant une copie des fichiers sur un autre disque et, pour chaque échec de la recopie, ordonnant une commande de déplacement de l'objet interne à l'espace du volume à destination du répertoire de QUARANTAINE.

[Autant l'avouer illico : je n'ai pas la pratique des scripts. Ce n'est pas que je ne « pourrais » pas, dans l'absolu. Mais c'est comme pour n'importe quel domaine, en ce qui concerne tout un chacun d'entre nous. Nous sommes tous porteurs de la « forme universelle de la raison », qui est la même chose que le « bon sens », « également partagé en tous les hommes » selon la déclaration de Descartes. Mais nous n'exerçons pas cette puissance en tous les domaines. Division du travail oblige. Spécialisation de l'expertise... Nous pouvons juger équitablement des résultats une fois survenus, non forcément les produire équitablement.

L'informatique n'est absolument pas mon domaine de spécialité, en tant que langage de programmation. Je me contente de transposer les protocoles généraux de la logique dans ce domaine spécialisé et disons que ça marche jusqu'à un certain point de précision et de complexité. Je n'ai aucune difficulté dans les commandes du «Terminal» (qui sont des propositions logiques de type « atomique » ou « moléculaire » d'une syntaxe limpide), mais je n'ai pas la pratique du « discours informatique » (qui est un programme complexe). Je me borne au « discours rhétorique » qui est davantage dans mes cordes
361608_original.png
]


Essaie donc l'opération a la mano (finalement, le nombre des cibles n'est pas trop grand et tu as une liste des proscrits) pour voir si tu arrives à les cantonner dans un coin : un dossier alternatif, ou un sous-dossier, ou encore un départ d'intitulé modifié, pour chaque fichier incriminé, par exemple en commençant leur titre par un _ de manière à les isoler ensemble du classement des autres. Voire encore essayer de placer un . en tête de leur intitulé, ce qui les rendrait invisibles. Ou un caractère comme x en départ de chaque intitulé.

Si tu parvenais à cette "ségrégation", soit topique (un autre dossier de collationnement), soit nominale (une modification commune de départ d'intitulé), il serait aisé de placer une commande de recopie de tous les autres sauf ceux-là et, si ça avait marché, de suppression sur la "source" (le volume Sans titre) de tous les fichiers recopiés, sauf les proscrits.

Ensuite, l'utilitaire dd pourrait peut-être récupérer la masse des blocs des proscrits sur un autre disque assez vite, s'il n'y en a que 240 et si c'était la seule occupation résiduelle du volume Sans titre, ce qui ne devrait pas faire un poids très lourd. Sinon, comme j'ai tenté de te le faire sentir dans mon message précédent, lancer une opération dd sur 176 Go c'est déclencher un processus fastidieux qui s'étalerait sur des jours et des jours...
 
Hello @macomaniac , un petit mot pour te remercier de ta dévotion, grace à tes conseils j'ai pû retrouver la quasi intégralité de mes sons qui sont maintenant en lieuX surs.

Tu n'as pas la "pratique des scripts" comme tu dis mais tu m'as quand-même donné un sérieux coup de main et si jamais tu as une amazon wishlist je pourrais volontier t'offrir quelque chose.

Merci pour tout, bonne fin de journée !
 
:coucou: Robin

Tout est bien qui finit bien, alors. Ton endurance et ton ingéniosité y sont pour beaucoup.

Je te conseille, dans l'«Utilitaire de Disque», d'« Effacer » le disque complet de ton DDE (Table de Partition GUID pour le disque > format OS X étendu journalisé pour le volume) => histoire d'être sûr du dispositif logique de ce DDE. Mais apparemment, c'était un sous-ensemble de fichiers musicaux corrompus, dans l'ensemble de ton imposante bibliothèque de sons, qui bloquait les opération de recopie.
 
Bravo à Robin pour sa persévérance!

Maintenant reste à déterminer l'origine de la corruption des fichiers.
Est-ce une origine "logique" (des problèmes logiciels lors de la copie des fichiers sur le disque), auquel cas un bon formattage du disque va permettre de repartir sur des bases saines,

Ou est-ce une origine "matérielle" avec des secteurs du disque défectueux qui rendent illisibles les portions de fichiers qui y sont copiées, auquel cas, personnellement, j'hésiterais à continuer à utiliser ce disque dont la fiabilité devient incertaine.

Je n'ai aucune idée de la meilleure façon de tester le disque pour s'assurer de son intégrité physique...
 
Bonjour remy,

Je pense que ça vient du disque car sur les dernières connexions, le disque a mis de plus en plus de temps à être reconnu et à m'afficher les fichiers. A mon avis il est fin de vie et je vais le déposer au cimetière des disques. Ce qui est étonnant par contre c'est qu'il bloquait toujours sur les même fichiers. Là une fois les musiques transférées elles sont lisibles sans problème et ça je ne me l'explique pas....