content comparison - how does it compare?

[primexx]

I'm curious how the content comparison works under the hood. Does it use hashing? straight up bit-for-bit comparison?

and particularly, does the comparison run through the whole file always or does it just break and start copying as soon as it sees the first bit that is different?

[Plerry]

FFS does a full (bit-by-bit, if you like) comparison.
FFS can/does not use a hash.
Using hashes would require software to run locally at each of the locations involved in the sync, which is often not possible.
FFS only needs to run on any single machine that can access each of the locations involved in the sync.

I suppose (but, I'm not sure) FFS stops the comparison (of any pair of left-right files) as soon as it discovers any differences.
However, FFS will not start copying/syncing "as soon as it sees the first bit that is different".
FFS always first finishes its complete compare-phase (of all files involved) before automatically or manually starting the sync-phase.

[primexx]

Oh thanks, yeah that makes sense. I suppose what I really want to know is whether it stops comparison of a file as soon as it sees the first different bit, or if it still compares the rest of the file anyway. Seems like it'd be most efficient to stop and move on as soon as it knows that the file has at least 1 difference.

[xCSxXenon]

Exactly the case. There is no reason to continue a compare when there is even a single bit difference

[polyglotinc]

hmmmm...I have files that repeatedly show as not equal by FFS (latest version), but when I compare them with Hex Fiend, that finds no differences.
It would really help to get more info from FFS about what it thinks is different and where.

[xCSxXenon]

Probably timestamps, which aren't in the file

[therube]

I have files that repeatedly show as not equal by FFS

What comparison method?
If by Content, date/time are ignored.
If by Time and Size, obviously different dates (& sizes) will affect results.