» s'était donc loupé en fin de clonage (une occurrence des plus rare avec ce logiciel) et n'avait pas "
à l'écran de choix du disque de démarrage (touche "alt" au départ) et, par suite, démarrable après sélection volontaire de la part de l'utilisateur. Lacune rectifiée.
☞ crains-tu que la commande de
blessing du volume de ton clone ait "
corrompu" en quoi que ce soit son système de fichiers, au point qu'un démarrage sur le clone ferait encourir des risques à certains services liés à internet (cloud, messagerie)? - Si ta crainte ne concerne que cette relation de cause à effet éventuelle :
blessing --> corruption du volume du clone, alors je t'arrête tout de suite --> problème
imaginaire.
Parce que le
blessing du volume d'un clone n'
ajoute pas quelque chose de "parasite" à ce qui serait, sans cela, une image-miroir parfaite du système de fichiers original : celui du volume de l'OS ; mais, au contraire,
parachève ce statut d'image-miroir qui, sans cela, serait affectée d'une
lacune. En effet, lorsque le
Programme d'Installation de l'installateur (téléchargé depuis l'AppStore) d'une version d'
OSX a fini de copier sur le disque du Mac le système de fichiers de l'OS, il termine toujours cette tâche par une commande de
blessing du volume qui lui permet d'être reconnu comme
bootable par le
DiskManager en cas de démarrage optionnel avec la touche "alt" --> c'est une sorte de
final touch extrinsèque à la recopie du système de fichiers d'après les
packages d'installation de l'OS. Or, lorsque le logiciel «
Carbon Copy Cloner» active sa tâche de clonage du système de fichiers du volume de l'OS sur le volume externe d'un DDE, cette tâche est capable de recopier terme à terme l'ensemble de ce système de fichiers... sauf le
blessing du volume qui ne fait pas partie du "
contenu" de ce système de fichiers, mais de l'"
en-tête" (header) de ce système de fichiers qui échappe au clonage. Aucun clonage ne peut importer le
blessing de l'en-tête du système de fichiers original dans le système de fichiers-miroir de la destination, car, pour prendre une image, le clonage part toujours de la "
tête" du système de fichiers, et jamais de son "
en-tête" qui devance la "
tête" en question. Le clonage part de la "
racine" logique du système de fichiers (le
/ du point de montage du volume), mais par là-même laisse échapper ce qui devance la "
racine" comme condition préalable du montage en volume.
Si je te t'ai pas rebuté par cet exercice "
malicieux" (si l'on y prête garde) d'«
ontologie informatique», il devrait paraître clair qu'
après la recopie du système de fichiers original sur le volume de destination (recopie qui est partie de la "
tête" du système de fichiers en question, càd. de la
racine logique /), il reste à tout bon logiciel de clonage qui se respecte à
répéter sur l'
en-tête de la destination le
geste même original du
Programme d'Installation de l'OS du disque du Mac : à savoir la "
bénédiction" du
header, sans quoi il y aurait une lacune du clone par rapport à l'original, en ce qui concerne sa possibilité d'être géré en tant que volume
bootable par le
DiskManager.
DiskManager qui est une sorte de chien rapporteur au service du Programme Interne du Mac (l'
EFI).
--------------------
☞ mais peut-être erré-je dans ces entrelacements
rhétoriques suscités par le démon de la
Malice qui se tient toujours perché sur mon épaule gauche... Peut-être tes craintes n'ont-elles rien à voir avec une corruption imaginaire que la commande de
blessing imposerait au système de fichiers d'un clone, mais, tout à fait indépendamment, sur les problèmes induits éventuellement par le
démarrage sur un clone tout court, par rapport à l'usage courant de l'OS original ?
Démarrer sur le
doublon d'un OS, résidant sur un disque indépendant de celui du Mac, cela ne crée-t-il pas un problème d'
identité par rapport à des services internet, parce qu'il est clair que l'utilisateur qui se présente comme le
même que celui de l'OS original, nonobstant se montre l'opérateur d'un "
ordinateur" qui n'est pas le
même que celui de cet OS original - par quel "or
dinateur" j'entends à la manière d'Apple une bécane physique mise-en-œuvre par un Système Logique qui a forcément un
UUID qui ne peut pas être le
même que celui du Système Logique original, mais un
autre ?
Il me semble, sur ce point, que la question se règle via une
ré-identification de l'utilisateur. Afin qu'il fasse la preuve qu'il est bien
le même en tant qu'utilisateur d'ordinateurs
existant séparément. Un clone permettant au Mac de démarrer à partir d'un disque externe produit un ordinateur qui a une
existence séparée par rapport à celui engendré par un démarrage sur le disque interne, tout en offrant des paramètres logiques miroir --> la question se règle en demandant à l'utilisateur de faire la preuve qu'il est bien
le même en tant qu'opérateur. Donc en ré-intialisant certains services grâce à ses identifiants. Par exemple, aucun démarrage sur un clone n'est automatiquement admis par la
DropBox sans ré-identification de l'utilisateur à qui il est demandé de prouver par ses identifiants qu'il est
le même, quoiqu'utilisant un "
ordinateur" existant séparément de l'ordinateur original...
Les sites internet requérant un
login, de même que les applications non tâtillonnes impliquant un n° de licence sans mesurer le nombre d'ordinateurs habilités à les faire fonctionner, ne posent aucun problème de reconnaissance : le clone comportant un doublon du
Trousseau de session de l'utilisateur, ce dernier renseigne automatiquement les identifiants.
Les applications issues d'éditeurs pour qui
un sou est un sou et cantonnant l'usage de leurs logiciels à un seul ordinateur sont susceptibles de poser des problèmes à l'emploi, dès lors qu'un démarrage sur le clone implique la génération d'un ordinateur doté d'une
existence séparée par rapport à l'original. Mais, en cas de rétro-clonage sur le disque du Mac (suite à un problème du système de fichiers original), la situation se trouve en principe rétablie puisque l'ordinateur se trouve re-créé à l'identique de l'originel.
Pour ce qui est de services de messagerie, il faut prendre garde, avant de les utiliser à partir d'un clone, aux préférences qui ont été établies :
conservation d'une copie des messages sur le fournisseur d'accès ou
suppression de ces messages. Moi-même, par exemple, j'utilise un compte POP basique avec l'option :
supprimer les messages du serveur après téléchargement. Il est clair, dans ces conditions, que relever des messages à partir du logiciel de messagerie d'un clone les
supprime du serveur, de sorte qu'ils ne seront pas accessibles en cas de re-démarrage sur l'OS original du Mac. Dans ces conditions, je m'abstiens soigneusement de lancer ces logiciels de messagerie quand je suis sur un clone. S'il le fallait (parce que le disque du Mac serait HS et qu'il me faille attendre avant de pouvoir le remplacer), alors je sais qu'un simple rétro-clonage sur le disque changé du Mac me ferait récupérer la base de données de messagerie
à la page...
[Pour
iCloud, cherche un autre avis : je n'utilise pas ces services...]
--------------------
