Does FFS Compare feature validate file integrity?

[jodee]

Hi. My original backup method would be to copy/paste files and folders from Drive A (primary) to Drive B (backup). When I eventually discovered FFS, I would still use the copy/paste method but then run FFS Compare to make sure both drive contents were identical. I assumed that as long as FFS Compare doesn't show any differences, the Drive B copies should be successful duplicates with no errors. Would this be a safe assumption? If not, how else can I quickly validate integrity (without having to test by opening each and every file)? Thanks.

[Plerry]

> Would this be a safe assumption?

This is a safe assumption, within the limitations also described for (and in the link in) the VerifyCopiedFiles flag.
If you use FreeFileSync (FFS) just to binary compare (without previous FFS sync), the likelihood of reading from a buffer (instead of the actual file) is even smaller.

[xCSxXenon]

"VerifyCopiedFiles" is only for data transferred with FFS, so it will not help if you are still manually copying data. Use FFS for the sync process and this will help though.
This doesn't work long-term though, as a file might never get updated, so it never gets written again, so it never gets verified, but it could still get bit rot. This is where comparing by file content would help, because it compares the binary content directly. This takes many multiple times as long though, since it is reading all of your files to accomplish this. You aren't going to want to do this for very long, and you'll give up on it lol
Bit rot is pretty rare, but this is why having multiple backups and verifying them occasionally is a thing. There are some programs I have seen that keep track of file hashes to determine if something changed unexpectedly. These are usually only done on enterprise-level storage servers though, but maybe you're into that kind of thing.

[jodee]

> Would this be a safe assumption?

This is a safe assumption, within the limitations also described for (and in the link in) the VerifyCopiedFiles flag.
If you use FreeFileSync (FFS) just to binary compare (without previous FFS sync), the likelihood of reading from a buffer (instead of the actual file) is even smaller.

"VerifyCopiedFiles" is only for data transferred with FFS, so it will not help if you are still manually copying data. Use FFS for the sync process and this will help though.
This doesn't work long-term though, as a file might never get updated, so it never gets written again, so it never gets verified, but it could still get bit rot. This is where comparing by file content would help, because it compares the binary content directly. This takes many multiple times as long though, since it is reading all of your files to accomplish this. You aren't going to want to do this for very long, and you'll give up on it lol
Bit rot is pretty rare, but this is why having multiple backups and verifying them occasionally is a thing. There are some programs I have seen that keep track of file hashes to determine if something changed unexpectedly. These are usually only done on enterprise-level storage servers though, but maybe you're into that kind of thing.

Thank you for both of your replies. It looks like I'll have to spend the next week going through each copied file just to make sure!

By the way, when performing a Mirror Sync, do you have to run Compare beforehand -- or does FFS automatically do that via Sync? I'd want to avoid unnecessarily wearing out the drive with possible duplicate Compare runs.

[xCSxXenon]

By the way, when performing a Mirror Sync, do you have to run Compare beforehand -- or does FFS automatically do that via Sync? I'd want to avoid unnecessarily wearing out the drive with possible duplicate Compare runs.

Doesn't matter. Clicking sync first will run a compare first. Clicking sync after running a compare manually just runs the sync with the actions queued by that compare. With that said, reading doesn't really "wear" drives anyway, so worry not.