Tengo una memoria USB que uso con frecuencia, lo que da como resultado que se creen muchos archivos ._*
, que elimino periódicamente ejecutando algo como find /Volumes/Secure -name '._*' -exec rm -vf {} \;
, y nunca antes había arruinado nada. Sin embargo, parece que algo se rompió durante esta última ejecución.
Aquí está la salida de la consola del comando find
/ rm
:
[Tue Aug 14 09:39:12]{1:126}jdoe@MacBook-Pro:/Volumes/Secure(✓)$ find -d . -name '._*'
./tor/TorBrowser-Data/Browser/Caches/1blvjd07.default/startupCache/._startupCache.8.little
./tor/TorBrowser-Data/Browser/Caches/1blvjd07.default/safebrowsing/._test-malware-simple.pset
./tor/TorBrowser-Data/Browser/Caches/1blvjd07.default/safebrowsing/._test-phish-simple.pset
./tor/TorBrowser-Data/Browser/Caches/1blvjd07.default/safebrowsing/._test-unwanted-simple.pset
# TRUNCATED
./tor/TorBrowser-Data/Browser/Caches/1blvjd07.default/safebrowsing-to_delete/._test-flashsubdoc-simple.pset
./tor/TorBrowser-Data/Browser/Caches/1blvjd07.default/safebrowsing-to_delete/._testexcept-flashsubdoc-simple.pset
[Tue Aug 14 09:39:18]{1:127}jdoe@MacBook-Pro:/Volumes/Secure(✓)$ find -d . -name '._*' -exec rm -vf {} \;
find: .: Invalid argument
(No estoy seguro, pero tal vez tenga algo que ver con {}
no estar entre comillas. No recuerdo si usé comillas en el pasado)
Cuando monto el volumen, puedo ver bien el contenido siempre que no haga referencia al contenido mediante una ruta relativa mientras estoy en el volumen montado (PWD).
He aquí un ejemplo de lo que quiero decir. Puede ver que puedo enumerar el contenido de /Volumes/Secure
muy bien. Pero si lo cd, luego intento enumerar el contenido del directorio actual, no funciona:
[Tue Aug 14 09:46:02]{1:193}jdoe@MacBook-Pro:/Volumes(✓)$ df /Volumes/Secure
Filesystem 512-blocks Used Available Capacity iused ifree %iused Mounted on
/dev/disk4s1 35372096 1566528 33805568 5% 0 0 100% /Volumes/Secure
[Tue Aug 14 09:46:06]{1:194}jdoe@MacBook-Pro:/Volumes(✓)$ ls /Volumes/Secure
chemdocs credentials data.tar.gz.enc scripts test test-data test-data.tar.gz.enc tor
[Tue Aug 14 09:46:09]{1:195}jdoe@MacBook-Pro:/Volumes(✓)$ cd /Volumes/Secure
[Tue Aug 14 09:46:11]{1:196}jdoe@MacBook-Pro:/Volumes/Secure(✓)$ ls
.
Entonces, solo para hacer esto un poco más confuso y frustrante, parece ser intermitente...
[Tue Aug 14 09:46:09]{1:195}jdoe@MacBook-Pro:/Volumes(✓)$ cd /Volumes/Secure
[Tue Aug 14 09:46:11]{1:196}jdoe@MacBook-Pro:/Volumes/Secure(✓)$ ls
.
[Tue Aug 14 09:52:28]{1:27}jdoe@MacBook-Pro:/Volumes/Secure(✓)$ ls .
.
[Tue Aug 14 09:52:30]{1:28}jdoe@MacBook-Pro:/Volumes/Secure(✓)$ ls -alrth .
total 30240
drwxrwxrwx 1 jdoe staff 16K Jun 18 18:20 .Spotlight-V100
drwxrwxrwx 1 jdoe staff 16K Jul 3 12:10 test-data
drwxrwxrwx 1 jdoe staff 16K Jul 3 12:10 .info
# TRUNCATED SOME LINES
drwxrwxrwx 1 jdoe staff 16K Aug 11 03:41 .Trashes
drwxrwxrwx 1 jdoe staff 16K Aug 11 03:41 .TemporaryItems
drwxrwxrwx@ 1 jdoe staff 16K Aug 13 19:22 .
drwxrwxrwx 1 jdoe staff 16K Aug 14 09:43 .fseventsd
drwxrwxrwt@ 7 root admin 238B Aug 14 09:43 ..
[Tue Aug 14 09:52:32]{1:29}jdoe@MacBook-Pro:/Volumes/Secure(✓)$ ls -alrth ./
ls: ./: Invalid argument
[Tue Aug 14 09:52:34]{1:30}jdoe@MacBook-Pro:/Volumes/Secure(0)$ ls -alrth .
ls: .: Invalid argument
[Tue Aug 14 09:52:36]{1:31}jdoe@MacBook-Pro:/Volumes/Secure(0)$ ls -alrth .
ls: .: Invalid argument
[Tue Aug 14 09:52:37]{1:32}jdoe@MacBook-Pro:/Volumes/Secure(0)$ ls
.
( Aquí hay una idea general con una salida de consola adicional )
He probado a desmontar y volver a montar sin éxito.
Cualquier entrada sería apreciada, ¡gracias!
-J
Actualización Acabo de notar algo más que es bastante interesante... Estos problemas que mostré arriba son todos exclusivos de la CLI. Puedo abrir la unidad montada en Finder y explorarla sin problemas... Extraño.
Los síntomas que describe son los signos de un sistema de archivos corrupto, que es el destino habitual de la llave USB de uso frecuente.
Haga una copia de seguridad de su llave USB y ejecute fsck
o Disk Utility
en su sistema de archivos.
Incluso te aconsejo que lo compruebes completamente con:
• copia de seguridad completa,
• borrado seguro completo con una pasada de 0 (para asegurarse de escribir en todos los bloques),
• hacer un nuevo FS,
• recuperar desde la copia de seguridad.
No find
causa ningún problema, ya que -exec
un shell no evalúa el argumento, no tiene que protegerlo contra la evaluación.
fsck
? Lo intenté diskutil repairVolume /dev/disk4s1
sin éxito, así como algunas otras cosas.-exec
opción de find
no ejecuta el comando usando el shell, por lo que no hay necesidad de preocuparse por los nombres de archivo extraños. En cualquier caso, si usa "{}"
, el shell eliminará las comillas de todos modos y find
no las verá, por lo que usar comillas no hace daño. Si ejecuta el comando de búsqueda desde un shell inusual, por otro lado, es posible que necesite comillas para evitar que ese shell haga cosas raras con las llaves.Disk Utility
verificación?
fd0
dan
unmount
error?