Tengo 2 archivos iguales que residen en un sistema de archivos NTFS:
Romans-MacBook-Pro:cut poma$ md5 src.mov
MD5 (src.mov) = 7d59d01e5efffe3a258eff86d8b775a0
Romans-MacBook-Pro:cut poma$ md5 copy.mov
MD5 (copy.mov) = 7d59d01e5efffe3a258eff86d8b775a0
Según ls
tengan los mismos tamaños y los mismos atributos:
Romans-MacBook-Pro:cut poma$ ls -l@
total 10681888
...
-rw-r--r--@ 1 poma staff 290300838 Jan 19 13:56 copy.mov
com.apple.quarantine 22
Mac_Metadata 20
-rw-rw-rw-@ 1 poma staff 290300838 Jan 19 13:12 src.mov
com.apple.quarantine 22
Mac_Metadata 20
Pero según Finder y mdls
tienen diferente tamaño:
Romans-MacBook-Pro:cut poma$ mdls src.mov
kMDItemFSContentChangeDate = 2015-01-19 06:12:45 +0000
kMDItemFSCreationDate = 2015-01-05 04:54:25 +0000
kMDItemFSCreatorCode = ""
kMDItemFSFinderFlags = 0
kMDItemFSHasCustomIcon = 0
kMDItemFSInvisible = 0
kMDItemFSIsExtensionHidden = 0
kMDItemFSIsStationery = 0
kMDItemFSLabel = 0
kMDItemFSName = "src.mov"
kMDItemFSNodeCount = 290301124
kMDItemFSOwnerGroupID = 99
kMDItemFSOwnerUserID = 99
kMDItemFSSize = 290301124
kMDItemFSTypeCode = ""
Romans-MacBook-Pro:cut poma$ mdls copy.mov
kMDItemFSContentChangeDate = 2015-01-19 06:56:04 +0000
kMDItemFSCreationDate = 2015-01-19 06:56:04 +0000
kMDItemFSCreatorCode = ""
kMDItemFSFinderFlags = 0
kMDItemFSHasCustomIcon = 0
kMDItemFSInvisible = 0
kMDItemFSIsExtensionHidden = 0
kMDItemFSIsStationery = 0
kMDItemFSLabel = 0
kMDItemFSName = "copy.mov"
kMDItemFSNodeCount = 290300838
kMDItemFSOwnerGroupID = 99
kMDItemFSOwnerUserID = 99
kMDItemFSSize = 290300838
kMDItemFSTypeCode = ""
AFAIK las bifurcaciones de recursos deberían aparecer ls -l@
como com.apple.ResourceFork
atributo. No hay tal atributo en mi archivo. ¿Cuál puede ser la diferencia entre ellos?
ACTUALIZACIÓN: No me di cuenta al principio. Ambos archivos residen en el sistema de archivos NTFS al que se accede a través del controlador Paragon NTFS v12.
Esto probablemente se deba a cómo el controlador Paragon maneja la compresión NTFS nativa. Si entiendo sus documentos correctamente, puede descomprimirse sobre la marcha, pero en realidad no puede volver a escribir el archivo en estado comprimido.
De su página de preguntas frecuentes :
Puede confirmar sus sospechas desde Windows, utilizando las herramientas estándar de Windows: https://technet.microsoft.com/en-us/library/cc976811.aspx
(Desafortunadamente, no he encontrado ninguna herramienta que pueda confirmarlo desde Paragon)
Lo primero que intentaría es decirle a Spotlight que vuelva a indexar el archivo. Podría ser que los metadatos en el índice de Spotlight estén desactualizados (nunca había visto esto antes, pero nunca se sabe). Simplemente ejecute el siguiente comando para decirle a Spotlight que vuelva a indexar el archivo.
mdimport /path/to/src.mov
También puede ejecutarlo con cantidades -d 1
variables -d 4
de información de depuración de la siguiente manera.
mdimport -d 1 /path/to/src.mov
Si eso no hace ninguna diferencia, dados los diferentes tamaños de archivo y el hecho de que (según su pregunta anterior ) Unison no pudo hacer una copia de seguridad del archivo, sospecho que está dañado en el sistema de archivos.
Creo que Paragon agrega la capacidad de verificar y reparar volúmenes NTFS dentro de la Utilidad de disco. Puede intentar verificar y reparar el volumen y luego verificar el archivo original para ver si se modificó el tamaño. Si es posible conectar este volumen a una máquina con Windows, también puede intentar ejecutar CHKDSK contra él.
mdimport
no hizo ninguna diferencia. Y no es corrupción de FS porque todos los archivos creados por un determinado programa (herramienta de video) tienen tales propiedades.
sin ladera
Poma
cp
marca setchell
Poma
sin ladera
src.mov
en Finder, ¿qué tamaño tiene el archivo duplicadols
después?Poma
ls
. En Finder y el archivo duplicado 'mdls' tiene el mismo tamañocopy.mov
y es diferente desrc.mov
.Poma