Hé ! Comme j'aime bien expérimenter (et pas seulement spéculer au plan logique
- histoire de soumettre le spéculatif à l'épreuve de l'expérience) => j'ai donc expérimenté d'une part une commande
».
). La première clé est donc identifiée dans son disque comme
- a) expérience en ligne de commande («
Terminal»).
Je saisis la commande canonique :
Bloc de code:
sudo asr restore -s /dev/rdisk1s1 -t /dev/disk2s1 --erase --noprompt
et j'obtiens en retour : un démontage instant des 2 volumes (qui cessent d'être affichés sur le Bureau) > et ce retour dans le «
Terminal» :
Bloc de code:
Validating target...done
Validating source...
Could not recognize "/dev/rdisk1s1" as an image file
done
Could not get source volume name
=> bref, un avortement d'entrée de la commande, au fait que la "
source" n'est pas reconnaissable (car le
container de la partition contient un format de fichiers
FAT-32). Pour ce qui est de la "
destination", pas de problème a priori, puisque
asr se réserve en principe le privilège d'effacer le système de fichiers de la "destination", et donc d'en reconstituer un neuf au format qui lui convient (=
jhfs+).
=> À l'issue de cet échec en ligne de commande, les 2 volumes sont démontés, mais tous les 2 remontables sans problèmes - aucun effet ne s'étant ensuivi.
--------------------
- b) expérience graphique («
Utilitaire de Disque 10.10.5»).
Je choisis l'option "
Restaurer" (
Restore) et je fais glisser sur la fenêtre de la "
source" le volume monté
SOURCE =
disk1s1 de la clé
disk1 > et sur la fenêtre de la "
destination" le volume monté
TARGET =
disk2s1 de la clé
disk2 > je presse le bouton "
Restaurer".
À ma grande surprise, après démontage préliminaire des 2 volumes (affichés en grisé) > un processus de restauration s'engage avec une barre de progression de la tâche et une durée d'opération fonction de la quantité de données présentes sur la "
source", de la connexion (USB-2 chez moi) et de la vitesse intrinsèque des disques (clés USB ici parmi les plus lentes du monde - j'achète toujours les clés le meilleur marché pour test et je collectionne donc les « rossignols »).
J'observe donc, ébranlé, ce « miracle » improbable : l'utilitaire
asr (piloté graphiquement par la fonction "
Restaurer") en train d'accomplir via l'«
Utilitaire de Disque» ce qu'il refuse d'accomplir via le «
Terminal», càd. la manifestation d'une « Contradiction Logique » qui me déconfit dans ma croyance au respect du « Principe d'Identité Logique » en informatique - tout en réveillant le démon sommeillant de la logique dialectique, qui est l'invalidation même de l'informatique...
... lorsque, à la fin de l'opération prétendue, voici qu'un panneau s'affiche dans l'«
Utilitaire de Disque» :
Bloc de code:
Échec de la restauration
Impossible de restaurer - Paramètre invalide
Pfuiiit ! J'ai eu chaud... Je voyais déjà un cas de « Logique Dialectique » (càd. de validité de la contradiction) intervenir dans l'informatique Mac (ce qui eût marqué son caractère unique : «
Think different ! ») > mais non : le processus avorte bien et bien.
Et comment avorte-t-il ? En laissant
démonté le volume
SOURCE de ma "
source" (
disk1s1) mais qu'il m'est aisé de remonter, sans perte de données. Par contre, en ce qui concerne ma "
destination" > pfuit ! plus de volume
TARGET, dont le système de fichiers a manifestement été complètement flingué pendant la tentative, et simplement l'affichage de l'identifiant de la partition
disk2s1. Partition déclarée "
Impossible à monter" : un format de système de fichiers
DOS_FAT_32 est toujours identifié dans ce
container, mais dépourvu de
nom de volume montable => autant dire qu'il est corrompu. L'«
Utilitaire de Disque» appelé à "
Réparer le disque" sur cette partition répond : «
Erreur : Utilitaire de disque ne peut pas réparer ce disque. Sauvegardez autant de fichiers que possible, reformatez le disque, puis restaurez vos fichiers sauvegardés ».
Une commande :
Bloc de code:
diskutil repairVolume disk2s1
renvoie un :
Bloc de code:
Started file system repair on disk2s1
Repairing file system
** /dev/rdisk2s1
Invalid BS_jmpBoot in boot block: 000000
File system check exit code is 8
Updating boot support partitions for the volume as required
Error: -69845: File system verify or repair failed
Underlying error: 8: POSIX reports: Exec format error
=> ce qui me désopile, car la recommandation de l'«
Utilitaire de Disque» de "
sauvegarder autant de fichiers que possible" est manifestement impossible à suivre en mode "
remontage d'un volume", puisque le système de fichiers est planté avec son secteur de boot d'un volume en vrac. Je présume, pour que la recommandation fasse sens, qu'elle signifie : "
employez un logiciel de récupération des données par scan des blocs" > ce qui porte l'
absurde à un échelon supérieur, puisque la partition dont il s'agirait de récupérer des données était la partition
cible de la restauration, càd. destinée à être
effacée avant restauration à partir de la source > comme quoi, à échapper la « logique dialectique », la logique identitaire n'échappe pas à l'absurde...
» (je respire, car sinon où irait-on, sans déterminisme identitaire ?). Néanmoins, l'absurde trouve à se loger dans l'espace de la non-contradiction, témoin cette
> pour déboucher sur un avortement de la restauration, parce que cette validation s'avère déficiente
.
L'« absurde » consisterait donc dans une « temporalité de l'échec » à l'intérieur d'un système logique identitaire autorisant une simulation provisoire de l'impossible.