¿Hay alguna forma de obligar a Finder a actualizar su información en uso para archivos grises (inaccesibles)?
Detalles:
Muevo archivos usados con poca frecuencia de mi Mac (OS X 10.6) a un servidor de archivos de Windows Server 2008. Recientemente encontré una gran cantidad de archivos que el Finder de OS X muestra en gris (como lo haría si el archivo estuviera en proceso de ser copiado). Los archivos en cuestión son todos válidos y completos: no están dañados ni faltan datos; de hecho, puedo acceder a los archivos desde la Terminal o desde una computadora con Windows sin problemas, pero Finder todavía cree que deberían considerarse inaccesibles.
Puedo "arreglar" el problema copiando el archivo original con un nuevo nombre, eliminando el archivo original, esperando unos minutos y luego renombrando el nuevo archivo con el nombre original (si no espero lo suficiente, el nuevo el archivo se volverá gris cuando se le cambie el nombre original).
Básicamente, parece que el Finder no ha podido borrar algunos indicadores de "en uso" o "incompleto" [conjetura].
Entonces, volviendo a la pregunta original: ¿cómo se puede solucionar esto? Idealmente, me gustaría poder escanear las unidades de red y encontrar y reparar todos los archivos grises a través de la Terminal o la operación Recursiva, para poder repararlos todos sin perder mucho tiempo.
Úselo ls -lapara verificar si el archivo tiene propiedades extendidas. Eso se verá similar a:
-rwxr-xr-x@ 1 user1 staff 439734882 Aug 16 21:34 myfile.zip
Mira al @final. Eso significa propiedades extendidas.
Para ver las propiedades extendidas, deberá usar el xattr -l filenamecomando.
En muchos casos, los archivos atenuados tienen un com.apple.FinderInfoatributo que se ve así:
com.apple.FinderInfo:
00000000 62 72 6F 6B 4D 41 43 53 00 00 00 00 00 00 00 00 |brokMACS........|
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000020
Para eliminar ese atributo, ejecute xattr -d com.apple.FinderInfo filenamey el archivo volverá a la normalidad.
Si necesita eliminar ese atributo de todos los archivos de forma recursiva, puede ejecutar:
xattr -dr com.apple.FinderInfo .
No se pierda el punto .al final que significa el directorio actual.
Publicación original: https://tangentlin.wordpress.com/2013/10/18/greyed-out-files-in-mac-osx/
¡Esto lo resolvió para mí! http://macadmins.psu.edu/news/2011/06/grayed_out_finder_folder
¿Entonces qué pasó? Parece que la fecha de creación de la carpeta se estableció en una fecha aleatoria en 1943. Si bien no estamos seguros de cómo sucedió, descubrimos cómo solucionarlo.
Usamos algunos archivos binarios que venían con las herramientas para desarrolladores, GetFileInfo y SetFile. GetFileInfo nos mostró la fecha de creación de la carpeta. Al principio lo pasamos por alto, pero al examinarlo más de cerca nos llamó la atención.
$ GetFileInfo Test/ directorio: "/Users/user/Desktop/Test" atributos: avbstclinmedz creado: 13/06/1943 06:13:00 modificado: 13/06/2011 15:07:33
Entonces podríamos cambiar la fecha de creación usando la herramienta SetFile.
$ SetFile -d 13/06/2011 Prueba/
Después de establecer la fecha en un tiempo razonable, podemos ver que realmente ha cambiado.
$ GetFileInfo Test/ directorio: "/Users/userid/Desktop/Test" atributos: avbstclinmedz creado: 13/06/2011 06:13:00 modificado: 13/06/2011 15:07:33
Luego, la carpeta se mostró correctamente en el Finder y se pudo volver a utilizar. También descubrimos que si creaba un alias de la carpeta, podía ver los datos y sacarlos. Una vez que se movió a otra carpeta, la carpeta anterior podría eliminarse.
Resolví esto usando el comando duplicado en la carpeta atenuada. Se podrá acceder a la nueva carpeta y los archivos se pueden mover a otra carpeta. Después de mover los archivos, elimine ambas carpetas (gris y copia), ahora ambas vacías
Intente eliminar sus cachés (~/Library/Caches) y reinicie. Mi experiencia ha sido que esto generalmente soluciona problemas extraños relacionados con iconos.
Puede intentar sincronizar los archivos nuevamente usando rsyncla herramienta:
$ rsync -aut /source/* /destination
o (si hay demasiados archivos):
$ find /source/ -name \* -type f -exec rsync -at {} /destination/ ";"
Estos son los argumentos a favor de BSD rsync:
-a, --archive archive mode; equals -rlptgoD (no -H,-A,-X)
-u, --update skip files that are newer on the receiver
-t, --times preserve modification times
Si está utilizando GNU rsync, considere agregar:
-N, --crtimes preserve create times (newness)
Nota: puede instalar GNU rsyncmediante brew install rsync.
Si esto no ayuda, intente también sin -u.
-N, pero puede agregarlo si tiene la versión GNU; de lo contrario, use la sintaxis BSD.-Nmarcado funcionó para mí. No estoy seguro si fue por la -Nbandera.¡Eureka! Me di cuenta de lo que está causando el problema.
Los archivos se copian a un recurso compartido de red de Windows Server 2008 con replicación DFS (a otro servidor). De alguna manera, Finder está almacenando en caché el estado "ocupado" del archivo; y esto ocurre a veces mientras se replica el archivo.
La solución alternativa es usar el terminal para duplicar el archivo, eliminar el original, ¡ESPERE! y luego cambiar el nombre del duplicado al nombre original. (Si no espera, el duplicado se volverá gris cuando cambie el nombre).
Ese es el "qué"; Todavía espero que alguien pueda explicar dónde se almacena en caché la información.
Si alguien puede averiguar dónde se almacena en caché la información y cómo identificar qué archivos se ven afectados en un script, aceptaré su respuesta; de lo contrario, marcaré esto como esta respuesta y escribiré el problema como una rareza de interoperabilidad entre OS/X y Windows.
Martín Marconcini
Itai Ferber
Roberto Altman