FreeFileSync Forum

No, it is highly unlikely FFS has a bug in the simple file comparison routine.
What exactly is the categorization you see in FreeFileSync for the "not equal"
files?

I assume, my skills are not like that, to do it...actually it would be enough
to know whether a file is equal to another or not.

So, do you mean FFS is buggy? And I rather should use other programs to find
out (none) equal files?

No it means you need to analyze the files yourself to see whats going on, e.g.
use a hex editor.

Thank you.

The other programs say the files are equal (one of them shows the difference),
so if that means - if I understand you right - they are equal, FFS is buggy
indeed...oy vey...and that means, that I may be have deleted files, which were
not equal.

OK, thanks again.

I don't know, are they equal? If "yes", FFS is right, the other tools buggy,
if "no", then it's conversely.

There are some files, e.g. rar files (e.g. 400 MB size), which FFS shows as
equal by content compare, but checksum calculators, e.g. HxD, HashMyFiles show
them as not equal.

What could that mean?

>Will FreeFileSync report file 1 as "changed" when I press "compare"
No, there is no way to detect that a file is corrupted except verify its
complete content. That is binary-compare against its allegedly uncorrupted
source or against a former checksum of same.

... avoid it, but how can one detect it order to repair it (e.g. by another yet valid copy of the data). Making sure data exists unaltered is done via checksums. This is inherent in file packer software, so the easiest way to make sure you are able to detect data corruption is put all your data into ...

... of copy errors, a file copy tool is not the right level to address this problem. Additional protection needs to be installed the form of file checksums, e.g. in the simplest case by using a packer which stores a CRC32 next to each file. In this case a correct data transmission can be guaranteed. ...

Hello, I´m only curious about how the content comparison works. It´s a bit by
bit comparison, CRC32 or MD5..? I´m wondering so that I can decide whether I
use it for integrity checks of different copies of my backups instead of a
checksum creation/verification tool. Thanks.

The data is directly binary-compared without calculating a hash value or a
checksum in between.

... among commercial ones. > leaning on the files size One obvious optimization would be to only test those files for equality (by calculating their checksum) whose filesize is equal. But even with the minimum number of candidates (=2) reading both files content (+ some CPU time, but the bottleneck ...