4

I have 2 same files residing on an NTFS filesystem:

Romans-MacBook-Pro:cut poma$ md5 src.mov 
MD5 (src.mov) = 7d59d01e5efffe3a258eff86d8b775a0
Romans-MacBook-Pro:cut poma$ md5 copy.mov 
MD5 (copy.mov) = 7d59d01e5efffe3a258eff86d8b775a0

According to ls they have same sizes and same attributes:

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 

But according to Finder and mdls they have different size:

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 resource forks should appear in ls -l@ as com.apple.ResourceFork attribute. There is no such attribute on my file. What may be the difference between them?

UPDATE: I didn't notice at first. Both files reside in NTFS filesystem which is accessed through Paragon NTFS driver v12.

  • How did you create the copy (via Finder, via Terminal, something else)? – nohillside Jan 22 '15 at 9:14
  • via Terminal using cp – Poma Jan 22 '15 at 9:30
  • 1
    Were they created on different filesystems? Different filesystems may have different extents or minimum allocation units... – Mark Setchell Jan 23 '15 at 22:25
  • 1
    No they are in the same folder – Poma Jan 23 '15 at 23:54
  • 1
    Added important filesystem details to the question – Poma Jan 28 '15 at 13:58
1

This is probably due to how Paragon driver handles native NTFS compression. If I understand their docs correctly, it can un-compress on-the-fly, but cannot actually write the file back in compressed state.

From their faq page:

  1. How does the NTFS for Mac® driver handle compressed files?
    NTFS supports its own compression feature. It is impossible (without a special copy routine) to copy compressed files or directories “as is” - because after the reading step we get the uncompressed file or directory. However, if the destination folder is compressed (on an NTFS partition), then the file or folder will be compressed too.

You can confirm your suspicions from Windows, by using standard Windows tools: https://technet.microsoft.com/en-us/library/cc976811.aspx
(Unfortunately, I haven't found any tools that can confirm it from Paragon)

  • The source file was created in OS X, so it cannot be compressed if what you say is true – Poma Jan 31 '15 at 11:40
0

First thing I'd try is telling Spotlight to reindex the file. Could be the metadata in Spotlight's index is just outdated (never seen this myself before, but you never know). Just run the following command to tell Spotlight to reindex the file.

mdimport /path/to/src.mov

You can also run it with -d 1 up to -d 4 for varying amounts of debugging information as following.

mdimport -d 1 /path/to/src.mov

If that doesn't make any difference, given the different file sizes and the fact that (according to your earlier question) Unison couldn't back up the file I'd suspect corruption in the filesystem.

I believe Paragon adds the ability to Verify and Repair NTFS volumes within Disk Utility. You could try verifying and repairing the volume, then checking the original file to see if the size has been modified. If connecting this volume to a Windows machine is a possibility you could also try running CHKDSK against it.

  • mdimport made no difference. And it is not FS corruption because all files created by a certain program (video tool) have such properties. – Poma Feb 5 '15 at 8:37
  • So only the files created by this tool are like this? Which video tool? – Alistair McMillan Feb 5 '15 at 9:07
  • All files rendered in DaVinci Resolve – Poma Feb 5 '15 at 13:37

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .