:coucou:
peyret
Quand je faisais des sauvegardes avec «
Carbon Copy Cloner» à destination du volume d'un DDE (attaché à mon
MacBook Pro 2011 en thunderbolt) ---> j'avais remarqué que le volume de destination du clone ne se laissait pas démonter immédiatement après l'achèvement de la tâche de clonage. Le panneau de tâche de «
CCC» disparu de l'affiche et l'application quittée.
Comme si effectivement un processus initié continuait d'utiliser le volume et n'avait pas été coupé net avec la complétion de la tâche de clonage proprement dite.
En patientant quelque temps > le volume se laissait alors démonter normalement > sans que j'aie à forcer le démontage.
J'ai "oublié" ce problème > parce qu'actuellement, ayant 2 SSD multi-partitionnés dans mon Mac, je clone de volume à volume toujours montés par défaut > ce qui fait que je ne me préoccupe plus de démonter le volume du clone pour éjecter le disque.
Ce petit acte de réminiscence m'amène à te demander : si tu laisses passer un
délai temporel à partir de l'arrêt du clonage et de la fermeture de «
CCC» --> est-ce que le volume du clone se laisse démonter normalement ?
Parce que le message de déni que tu obtiens quand tu te "dépêches" de démonter le volume :
le disque « cloneosxN » n'a pas été éjecté car il est peut-être utilisé par un ou plusieurs programmes
est typique d'un volume dont la
ressource est occupée par un processus actif.
----------
Je te suggère dans le «
Terminal» le petit test suivant --> tu saisis la commande :
Bloc de code:
sudo lsof +D /Volumes/cloneosxN
ce que tu peux faire commodément en ne tapant que :
> en sautant un espace > et en faisant un glisser-déposer direct au pointeur de l'icône de ton volume
cloneosxN > ce qui va inscrire automatiquement
/Volumes/cloneosxN dans le Terminal.
- cette commande appelle l'utilitaire lsof (list_open_files : lister les fichiers utilisés par des processus) > avec l'option +D (Directory) qui cible l'action de lsof sur le domaine d'un répertoire (qui peut être celui d'un volume monté, qui a le statut logique de répertoire de fichiers) - ce en mode récursif (sur toute la profondeur des fichiers du répertoire) > et l'adresse au dit répertoire, chez toi le volume cloneosxN
Je te déconseille d'exécuter la commande pendant que «
CCC» se trouve en train de cloner (parce que de toute façon aussi longtemps qu'il clonera la commande sera en
stand-by) > mais de la déclencher par une pression sur la touche "
Entrée" aussitôt que l'application «
CCC» aura quitté.
Tu ne vas rien voir pendant un bon bout de temps (tout dépend du nombre de processus qui peuvent être actifs) et d'un seul coup tu vas voir s'afficher le tableau de tous les processus recensés en train d'utiliser le volume.
Je viens de faire cette expérience sur le volume de destination d'un clonage, commande initiée juste au moment où «
CCC» vient de quitter. Voici le résultat :
Bloc de code:
kextd 70 root 7r REG 1,19 3083 8590699108 /Volumes/HS-APFS-clone/usr/standalone/bootcaches.plist
mds 92 root 25r DIR 1,19 1504 2 /Volumes/HS-APFS-clone
notifyd 129 root 171r DIR 1,19 1504 2 /Volumes/HS-APFS-clone
notifyd 129 root 172r DIR 1,19 416 8590658209 /Volumes/HS-APFS-clone/usr
notifyd 129 root 173r DIR 1,19 160 8590699107 /Volumes/HS-APFS-clone/usr/standalone
notifyd 129 root 174r REG 1,19 3083 8590699108 /Volumes/HS-APFS-clone/usr/standalone/bootcaches.plist
notifyd 129 root 175r DIR 1,19 224 8589935468 /Volumes/HS-APFS-clone/private
notifyd 129 root 176r DIR 1,19 1056 8589935469 /Volumes/HS-APFS-clone/private/var
notifyd 129 root 177r DIR 1,19 960 8590658038 /Volumes/HS-APFS-clone/private/var/run
notifyd 129 root 178r DIR 1,19 160 8590109038 /Volumes/HS-APFS-clone/System
notifyd 129 root 179r DIR 1,19 3264 8590109040 /Volumes/HS-APFS-clone/System/Library
notifyd 129 root 180r DIR 1,19 10752 8590283083 /Volumes/HS-APFS-clone/System/Library/Extensions
notifyd 129 root 181r DIR 1,19 2688 8590065950 /Volumes/HS-APFS-clone/Library
notifyd 129 root 182r DIR 1,19 672 8590087829 /Volumes/HS-APFS-clone/Library/Extensions
notifyd 129 root 183r DIR 1,19 128 8590434352 /Volumes/HS-APFS-clone/System/Library/Kernels
notifyd 129 root 184r REG 1,19 15670232 8591479529 /Volumes/HS-APFS-clone/System/Library/Kernels/kernel
notifyd 129 root 185r DIR 1,19 19360 8590482609 /Volumes/HS-APFS-clone/System/Library/PrivateFrameworks
notifyd 129 root 186r DIR 1,19 160 8590528304 /Volumes/HS-APFS-clone/System/Library/PrivateFrameworks/EFILogin.framework
notifyd 129 root 188r DIR 1,19 224 8590528312 /Volumes/HS-APFS-clone/System/Library/PrivateFrameworks/EFILogin.framework/Versions/A/Resources
notifyd 129 root 189r DIR 1,19 96 8590528313 /Volumes/HS-APFS-clone/System/Library/PrivateFrameworks/EFILogin.framework/Versions/A/Resources/EFIResourceBuilder.bundle
notifyd 129 root 190r DIR 1,19 224 8590528314 /Volumes/HS-APFS-clone/System/Library/PrivateFrameworks/EFILogin.framework/Versions/A/Resources/EFIResourceBuilder.bundle/Contents
notifyd 129 root 191r DIR 1,19 4224 8590528321 /Volumes/HS-APFS-clone/System/Library/PrivateFrameworks/EFILogin.framework/Versions/A/Resources/EFIResourceBuilder.bundle/Contents/Resources
notifyd 129 root 192r DIR 1,19 288 8590086088 /Volumes/HS-APFS-clone/Library/Caches
notifyd 129 root 193r REG 1,19 24494466 8590704408 /Volumes/HS-APFS-clone/Library/Caches/com.apple.desktop.admin.png
notifyd 129 root 194r DIR 1,19 4192 8590092021 /Volumes/HS-APFS-clone/Library/Preferences
notifyd 129 root 195r DIR 1,19 768 8590092027 /Volumes/HS-APFS-clone/Library/Preferences/SystemConfiguration
notifyd 129 root 196r REG 1,19 301 8590707508 /Volumes/HS-APFS-clone/Library/Preferences/SystemConfiguration/com.apple.Boot.plist
notifyd 129 root 197r DIR 1,19 448 8590192140 /Volumes/HS-APFS-clone/System/Library/Caches
notifyd 129 root 198r DIR 1,19 256 8590699134 /Volumes/HS-APFS-clone/usr/standalone/i386
notifyd 129 root 199r DIR 1,19 448 8590699135 /Volumes/HS-APFS-clone/usr/standalone/i386/EfiLoginUI
notifyd 129 root 200r DIR 1,19 192 8590482562 /Volumes/HS-APFS-clone/System/Library/PrelinkedKernels
notifyd 129 root 201r REG 1,19 26475498 8591482623 /Volumes/HS-APFS-clone/System/Library/PrelinkedKernels/prelinkedkernel
notifyd 129 root 202r DIR 1,19 5376 8590199983 /Volumes/HS-APFS-clone/System/Library/CoreServices
notifyd 129 root 203r REG 1,19 571960 8591456827 /Volumes/HS-APFS-clone/System/Library/CoreServices/boot.efi
notifyd 129 root 204r REG 1,19 97838 8591437268 /Volumes/HS-APFS-clone/.VolumeIcon.icns
notifyd 129 root 205r REG 1,19 481 8591456818 /Volumes/HS-APFS-clone/System/Library/CoreServices/SystemVersion.plist
notifyd 129 root 206r REG 1,19 5042 8591254412 /Volumes/HS-APFS-clone/System/Library/CoreServices/PlatformSupport.plist
notifyd 129 root 207r REG 1,19 881 8591538901 /Volumes/HS-APFS-clone/System/Library/CoreServices/.disk_label
Path\x20F 480 macomaniac 41r DIR 1,19 1504 2 /Volumes/HS-APFS-clone
Ahaaa ! d'aaaccord --> pas étonnant si le volume ne peut pas se démonter naturellement. Il y a foule de processus qui ont été déclenchés par l'acte de clonage. Si «
CCC» était toujours en train de cloner > ce serait le processus
rsync affiché (car il n'y a pas de lézard : «
CCC» utilise
rsync pour sa tâche).
Si j'épluche un peu le bazar --> je m'aperçois que :
- comme conjecturé par subsole :coucou: --> un mds (meta_data_service) a été déclenché pour indexer les différences du volume pour «Spotlight».
- un kextd a été alerté également sur le volume > à destination d'un fichier bootcaches.plist. C'est un daemon (comme montré par le d final) càd. un serveur de l'OS particulièrement redoutable : il s'agit d'un service de surveillance permanent (comme un radar) de tout ce qui relève des extensions du kernel (kext) - ce, quel que soit le volume monté (ce service n'est donc pas cantonné au dossier des Extensions de la Bibliothèque du Système du volume démarré). Sa fonction de surveillance va jusqu'aux caches de démarrage construits à partir du kernel et des extensions. Donc ici c'est un fichier bootcaches.plist = fichier de préférences des caches de démarrage.
- un notifyd particulièrement prolifique a également été alerté pour travailler au bénéfice du système de notification. Le d de notifyd indique que c'est encore un daemon --> c'est-à-dire un service de l'OS : un véritable serveur qui ne s'arrête jamais pendant que l'OS est démarré > et que la moindre alerte fait "fondre" sur la cible. Je ne sais pas si kextd a alerté launchd (le serveur des serveurs) qui l'a alerté --> en tout cas il est passionnant de voir que le serveur notifyd se contrefiche des fichiers personnels de l'utilisateur ou même des fichiers statiques de l'OS --> non : ce qui l'intéresse, c'est tout ce qui a trait aux conditions de démarrage du Système du volume : boot_loader boot.efi > cache prelinkedkernel > kernel > extensions du kernel > ressources efires de l'efi ...
Il a fallu largement plus d'un minute pour que la commande
lsof affiche le tableau. On peut imaginer que pendant ce temps-là > ce n'était pas la peine de vouloir démonter naturellement le volume.
Forcer le démontage > c'est envoyer un
signal d'extinction brutal à chacun des processus en tant qu'ils utilisent le volume. Il ne semble pas que ça puisse affecter les fichiers du volume > car ces processus agissent en
lecture sur les données du volume. Mais ce sont des processus puissants de l'OS (métadonnées et services d'extensions et de notifications). Ces serveurs ne sont bien entendu pas arrêtés, mais coupés dans leur activité à destination du volume.
Je pense qu'un volume recelant un Système fraîchement mis à jour est l'objet d'une "attention spéciale" de la part de serveurs toujours en activité de l'OS. En somme : de services de surveillance permanents. S'il s'agit d'un petit volume de clé USB ne contenant que des données sans Système > ces serveurs ne détectent rien et n'utilisent donc pas le volume.
En résumé : il vaut mieux attendre après un clonage que ça "refroidisse" --> que l'attention des serveurs de l'OS portés sur les
modifications du Système recelé par le volume se "détende"
