FFS content comparison and resource fork data

[polyglotinc]

Does the FFS content compare take into account the "resource fork" data (which may be in separate "dot" file or not)?

I get different results when copy-then-compare is done on a folder depending on whether FFS or Finder does the copy.
When FFS does the copy via Sync, all the normal and dot files are copied and show as time/size/content matches.
When Finder does the copy, FFS shows all the dot resource fork files as missing in the destination, but otherwise the files all show file time/size/content matches.

It seems odd that the Finder would ignore the resource fork dot files since it is supposed to know about them,
but on the other hand, if Finder collapsed the resource data back into the main file (as seems plausible given no dot files on in destination folder),
then it seems like FFS content compare should have failed (if it was taking resource fork data into account).

So, does content compare do anything with resource fork data (dot files or embedded fork).

BTW, source and destination drives for my tests were both Mac OS Extended (Case-sensitive, Journaled) file systems on external USB drives.

[Zenju]

No, resource fork data is not considered during binary comparison (Just like alternate data streams and other meta data aren't on Windows).

It seems odd that the Finder would ignore the resource fork dot files since it is supposed to know about them,
but on the other hand, if Finder collapsed the resource data back into the main file (as seems plausible given no dot files on in destination folder)

It would be interesting to find out whether Finder is ignoring the resource fork files during copy or is integrating them. And if latter is true, the question is if FreeFileSync is able to preserve these integrated resource forks during file copy.