FFS not detecting size differences

[AndrewS65]

I have a folder structure of my photograph collection on a 10TB external HDD (Format: MacOSX extended journaled) and mirror it to a Synology NAS over a wi-fi network. My usual routine is to use Chronosynch to mirror changes when there is a small number of files (triggering on date and size). CS is too slow for changes in many files and I can't see what is going on so I have started using FFS but have found that it does not detect some changes.
For example CS reports files are different in creation date and size (by 659 bytes) as follows:

Screenshot 2023-05-10 at 1.42.32 pm.png (65.3 KiB) Viewed 1787 times

and the properties (Get Info) show the 659 bytes are additional metadata, but the file size is identical between files:

Screenshot 2023-05-10 at 1.43.43 pm.jpg (258.31 KiB) Viewed 1787 times

FFS does not mirror these files as it does not detect them as different in either size, date or content comparisons. Even if FFS is not picking the file size difference as the OS reports no difference the creation dates are definitely different in the OS.

Any clues please? How do I get FFS to detect this file difference?

[therube]

In the FFS realm, time is Modified Time (rather then Created Time).
So in that respect Time & Size do equal, so there is nothing to sync.

If you did a Content comparison, that would obviously find the files to be different.

So yes, with Time & Size, you could have two totally dissimilar files & never know it.

[therube]

https://www.econtechnologies.com/chronosync/overview.html

Metadata changes such as access permissions, locked states, Finder labels, tags, Spotlight comments, etc. are detected and will be applied to a counterpart file if that is all that has changed.

Is this metadata, this 659 bytes, is that stored in a file, separate from the (picture in this case) itself?
Or is the metadata actually written into the picture file (like Exif data)?

If the former, then only the new (or changed) metadata file would need to be synced, & I would think that FFS should see that.

If the latter, & if the Exif writing application does not change the original file size/time (which you would expect it would not), that change would not be seen by FFS (when using a Time & Size compare).

(I know nothing of Mac, much less how it may handle metadata.)

[AndrewS65]

Thanks for replying!

Yes, the 659 bytes is EXIF data, but doesn't show in the overall file size when comparing the files, so it must be stored elsewhere. No hidden file is evident though.

Your responses prompted a little more digging and it looks like I have been sucked into the vacuum of Mac extended attributes (which appears to be where the extra data is stored) and the difficulties of getting NAS to preserve them.

When I directly copy a file to the NAS and compare the 2 files the exif data is lost, so it is clearly not stored in a way that is preserved by the NAS o/s. I've been googling "Synology preservation of extended attributes" and can't get a straight answer. Chronosynch even tells me when I ask it to preserve extended attributes that it isn't supported on my NAS (I just never realised what that meant).

Thanks again.

More digging.

[AndrewS65]

so...
the problem may be with chronosynch (or the way I have it set up).

FFS appears to be correct in saying their is no difference between the files. If I copy the file from the NAS to my Mac and then check it with GetInfo it has the same details as the original file on the Mac. CS is not correctly comparing the file size/date over the network whereas FFS is (somehow). Bonus to FFS!
Now how to get CS working the way I want it too.

[therube]

?
https://community.synology.com/enu/forum/1/post/125222
?
https://www.reddit.com/r/DataHoarder/comments/hw3m0u/data_loss_when_moving_files_from_mac_os/