A parte il riavvio del sistema, ci sono probabilmente una mezza dozzina di modi diretti, affidabili e perfettamente appropriati per completare il processo di detaratura completa di un'unità che si è arrestata inaspettatamente in modo prematuro al momento dello smontaggio. Avevo due comandi da terminale che avrebbero portato immediatamente a termine il lavoro, e li conosco entrambi abbastanza bene da non sentire la necessità di ricontrollare le pagine man prima di digitare. Detto questo, il mio consiglio è di affrontare la situazione ... riavviando il sistema. Lascia che il sistema operativo esegua la miriade di controlli di integrità di spegnimento e avvio e procedure di sicurezza di avvio multiplo e funzioni di recupero che non abbiamo idea nemmeno esistano. Mentre sono abbastanza avventuroso da montare immagini del disco con file shadow nel kernel [ /usr/sbin/hdik ], rimando all'autorità della struttura del filesystem locale quando si tratta di tenere d'occhio l'integrità delle mie unità di backup.
Suggerisco inoltre che prima di intraprendere qualsiasi azione diretta sull'unità, controlli il log di SuperDuper. Se qualcosa fosse andato Terribilmente, Terribilmente sbagliato, SuperDuper l'avrebbe annunciato in quel momento, quindi non è questo il motivo per dare un'occhiata. Lo suggerisco sulla strana possibilità di incontrare un suggerimento sulla fonte del problema tecnico.
Allo stesso modo, considera la possibilità di controllare /var/log/diskarbitrationd.log per la sua interpretazione degli eventi recenti e l'opportunità di una maggiore illuminazione. (Naturalmente, non dirò di dare un'occhiata al contenuto di /etc/fstab .)
modifica :: informazioni supplementari
I due comandi che mi sono venuti in mente erano umount * e diskutil.
Ho controllato la documentazione per umount per assicurarmi che la memoria del suo utilizzo fosse ragionevolmente accurata. Mi sono confrontato con la rivelazione che per, oh, vent'anni circa, avevo trascurato la sezione NOTE della pagina man, citata qui di seguito:
Due to the complex and interwoven nature of Mac OS X, umount may fail often. It is recommended that diskutil(1) (as in, ''diskutil unmount
/mnt'') be used instead.
Che cosa posso dire? A causa della natura complessa e intrecciata della mia capacità cognitiva residua, potrei fallire spesso.
Come per diskutil, il particolare comando che avrei emesso è risultato valido: diskutil unmountDisk force [device] . Ti consigliamo di consultare le pagine del manuale per le opzioni di utilizzo completo e la sintassi.
Riguardo alla non esistenza di /var/log/diskarbitrationd.log : apparentemente, hai scioccamente trascurato di crearlo ... Oh ... Aspetta ...
A volte [vedi ¶ quattro, sopra] dimentico che questo o quel processo in background che ho eseguito non fa parte di un'installazione OS predefinita. Questo era il caso qui con il demone del server di arbitraggio del disco, situato in /usr/sbin/diskarbitrationd . Non ha senso per te preoccupartene ora.
Se ti interessa, e per la tua convenienza, considera l'utilizzo di Utility Disco per esaminare lo schema di partizione dell'unità disco e il filesystem. Se sul dispositivo esiste più di un volume, il che probabilmente non è così per un'unità di backup, tieni premuto il tasto ⌘-Comando mentre fai clic sul nome del dispositivo insieme ai nomi del volume rientrato sotto di esso. Quindi utilizzare l'opzione Verify Disk nella scheda First Aid per verificare la presenza di errori nell'unità.
* Non è un refuso.
