¿Dónde se almacenan los metadatos de 'De dónde' cuando se descargan a través de Chrome?

Estoy ejecutando Mavericks con Chrome, y cuando descargo una imagen/archivo, guarda el 'De dónde' cuando lo veo a través de Obtener información. Esto también sucede en Safari.

Ahora, entiendo que hay un historial de descargas separado que se puede ver y eliminar a través de los trucos del siguiente artículo: http://www.cultofmac.com/179873/list-your-macs-entire-download-history-at -once-os-x-tips/ Se utilizan al abrir Aplicaciones por primera vez para mostrar al usuario de dónde provienen.

Sin embargo, eliminé esto y confirmé que está vacío, pero todavía se muestra en 'De dónde'. Realicé algunas pruebas adicionales y cargué la imagen para ver el EXIF ​​y los metadatos, pero no parece estar almacenado en absoluto en los metadatos de los archivos. Entonces, ¿dónde podría almacenarse?

¿Alguien sabe cómo se almacenan estos metadatos de 'De dónde' y dónde se almacenan? ¿Se queda con el archivo si coloca el archivo en la unidad USB y lo abre en una computadora diferente?

No estoy tan preocupado por quitarlo, pero no puedo ver de dónde viene.

¿También le apetece una respuesta programática que muestre cómo recuperar esta información para un archivo? Veo que confirmó la respuesta que lo explica "nivel de shell" ...

Respuestas (2)

Se almacena en un atributo extendido en el archivo. Específicamente el com.apple.metadata:kMDItemWhereFromsatributo. Puede permanecer con el archivo cuando lo mueve a diferentes computadoras, pero depende del sistema de archivos o del protocolo de uso compartido de archivos que utilice. Si lo mueve a otra Mac en un disco HFS+, es probable que lo conserve, pero no necesariamente si lo transfiere a través de la red, y muy probablemente no con un disco externo con un sistema de archivos que no sea HFS+.

Puede verificar un archivo ejecutándolo xattr -lp com.apple.metadata:kMDItemWhereFroms myfileen la Terminal o eliminarlo con xattr -d com.apple.metadata:kMDItemWhereFroms my file. ls -l@la bandera también es útil; enumerará los nombres de xattrs junto con la información habitual de ls.

Si desea eliminarlo de varios archivos, eche un vistazo a esta pregunta: ¿Cómo eliminar xattr com.apple.quarantine de todos los archivos .webarchive con ese atributo extendido?

Esa es una respuesta muy informativa, gracias. ¿Estaría en lo correcto al decir que el archivo contiene los datos del archivo, y luego hay un archivo de shell oculto que en realidad tiene el xattr agregado?
Cerca, pero no exactamente. Es más parecido a los metadatos. De la misma manera que un archivo tiene contenidos que son los datos reales, pero también un nombre, una fecha de creación, etc., puede tener adjuntos atributos extendidos.
@robmathers: joder, me has ganado. También me olvidé de la opción -l de xattr. Tener un voto a favor.
absolutamente no es un "archivo de shell oculto" El almacenamiento, la indexación, la búsqueda y la recuperación de metadatos son un tema importante, que no es muy fácil de abarcar o comprender. Solo recuerde que la función Spotlight se basa en estos metadatos (y los recopila) y hay componentes especiales que puede desarrollar para su aplicación que devolverán sus propios metadatos personalizados para sus archivos de documentos personalizados (llamados dinámicamente por el sistema operativo) y existe el archivo real. Atributos de metadatos admitidos por el sistema y más.

Hay atributos extendidos asignados a los archivos descargados, como com.apple.quarantineponer los archivos ejecutables en cuarentena y com.apple.metadata:kMDItemWhereFromspara los datos de "De dónde". La presencia de estos atributos se puede revelar en la Terminal a través de ls -l@ /path/to/downloaded/file.

Ahora, para obtener los datos reales almacenados en este kMDItemWhereFroms, encontré una solución basada en esta respuesta (que también explica un poco más sobre el método de conversión):

xattr -p com.apple.metadata:kMDItemWhereFroms /path/to/downloaded/file | sed -e 's/0D//g' -e 's/.*\(5F 10\)...//' -e 's/00.*//'| xxd -r -p | sed -e 's@ (.*@@g'

Esto devolverá la URL. Tenga en cuenta que en este momento está en una forma relativamente difícil de leer, ya que mi command-line-fu parece fallarme. Actualizaré la respuesta una vez que encuentre la adecuada sed.

Desde los primeros bytes, "bplist", supuse que era una plist binaria, así que aquí está cómo decodificarla usando las herramientas de Apple para leerlas: xattr -p com.apple.metadata:kMDItemWhereFroms "$file" | xxd -r -p | plutil -convert xml1 -o - -. Si desea obtener la(s) URL(s) (la mayoría de los archivos parecen tener dos) por su cuenta, lo correcto en este punto sería alguna herramienta XML general (como ) o alguna herramienta específica de plist (puede xpath' no te ayudo allí). (Probado en 10.8.5.)
@AaronDavies tienes razón! Desafortunadamente, las cadenas no parecen estar en un orden específico dentro del XML. Es bueno ver que esto también funciona en cosas como los archivos adjuntos de correo.