Además de reiniciar el sistema, es probable que haya media docena de formas directas, confiables y perfectamente apropiadas para completar el proceso de desconexión completa de una unidad que se detuvo inesperadamente de forma prematura en el momento del desmontaje. Me vinieron a la mente dos comandos de terminal que harían el trabajo de inmediato, y los conozco lo suficientemente bien como para no sentir la necesidad de revisar las páginas del manual antes de escribir. Dicho esto, mi consejo es tratar la situación ... reiniciando el sistema. Deje que el sistema operativo ejecute la miríada de comprobaciones de integridad de apagado y arranque y procedimientos de seguridad de tiempo de arranque de varios pasos y funciones de recuperación que ni siquiera sabemos que existan. Si bien soy lo suficientemente aventurero para montar imágenes de disco de archivos de sombra en el kernel [/usr/sbin/hdik
], Difiero a la autoridad de la estructura del sistema de archivos local cuando se trata de vigilar la integridad de mis unidades de respaldo.
Sugiero además que antes de participar en cualquier acción directa en el disco, verifique el registro de SuperDuper. Si algo hubiera salido terriblemente mal, SuperDuper lo habría anunciado en ese momento, así que esa no es la razón para echar un vistazo. Lo sugiero por la extraña posibilidad de encontrar una pista sobre la fuente del problema.
Del mismo modo, considere verificar /var/log/diskarbitrationd.log
su opinión sobre los acontecimientos recientes y la oportunidad de una mayor iluminación. (Naturalmente, no mencionaré echar un vistazo al contenido de /etc/fstab
).
editar :: información suplementaria
Los dos comandos que se me ocurrieron fueron umount
﹡ ydiskutil.
Revisé la documentación para umount
asegurarme de que mi memoria de su uso era razonablemente precisa. Me enfrenté a la revelación de que, durante unos veinte años más o menos, había pasado por alto la sección de NOTAS de las páginas del manual, completamente citada a continuación:
Debido a la naturaleza compleja y entretejida de Mac OS X, umount puede fallar con frecuencia. En su lugar, se recomienda utilizar diskutil (1) (como en `` diskutil unmount / mnt '').
¿Qué puedo decir? Debido a la naturaleza compleja y entretejida de mi capacidad cognitiva residual, puedo fallar con frecuencia.
En cuanto a diskutil, el comando en particular me hubiera emitido resultó ser uno válido: diskutil unmountDisk force [device]
. Querrá consultar las páginas del manual para conocer las opciones de uso completo y la sintaxis.
Con respecto a la inexistencia de /var/log/diskarbitrationd.log
: aparentemente, tontamente descuidaste crearlo ... Oh ... espera ...
A veces [ver ¶ cuatro, arriba] olvido que este o aquel proceso en segundo plano que estoy ejecutando no es parte de una instalación predeterminada del sistema operativo. Ese fue el caso aquí con el demonio del servidor de arbitraje de disco, ubicado en /usr/sbin/diskarbitrationd
. No tiene sentido que te molestes con eso ahora.
Si lo desea y, a su conveniencia, considere usar la Utilidad de Discos para examinar el esquema de partición y el sistema de archivos de la unidad de respaldo. Si existe más de un volumen en el dispositivo, lo que probablemente no sea así para una unidad de respaldo, mantenga presionada la tecla Comando while mientras hace clic en el nombre del dispositivo junto con los nombres de volumen sangrados debajo de él. Luego use la Verify Disk
opción en la pestaña Primeros auxilios para verificar si la unidad tiene errores.
﹡ No es un error tipográfico.