Do the databases contain the checksums of the files for later comparison?

[Liriz]

Hello,

I have discovered FreefileSync and would like to know a few things before i buy it.

First of all:
During the first synchronization between two disks with content comparison (bit by bit), do the databases thus produced on each side contain the checksum of each file for a later comparison ?

Cordially

[Plerry]

> ... before I buy it.
Simply try the free version. If you like FreeFileSync (FFS) you can donate.

FFS does not use checksums. See also here.

[Liriz]

I have tried it and find it really great.
Only i would like to understand the operation of the databases produced on each side. Do they contain the checksums of the comparisons of each synchronized file for later use ? Do you know ?

It is sometimes possible that a file at the source is corrupted without being modified and that it is better to recover it by overwriting it with an old copy on the side of the backup destination. While all other files that are left intact can be copied normally from the source to the backup destination. A real crossover of which I would like to know if FreefileSync has the necessary provisions for this kind of detections?

Since in this case neither timestamps can do anything.

[Plerry]

About the way FFS database files work, and although described in a different context: see here.
The described comparison between the stored status (in the local FFS database-file) and the actual local status is based on file date and size, and allows FFS to determine what changes (if any) have occurred in that location since the last sync and need to be synced to the opposite side. It is by no means a data integrity comparison.

Like stated before, FFS does not use checksums/hashes, and my earlier link elaborated on why.
As the name suggests, FFS is first and foremost a synchronization tool and does not structurally check data integrity at both sides on every sync, although it provides means to do a left-right data-content comparison (Compare by file content) and a verification when writing a file (VerifyCopiedFiles).

[Liriz]

Okay. Thanks Plerry for your explanation.

Maybe a good function to implement in the future.
Because I just encountered this kind of problem with a file on my source disk accidentally corrupted without FFS. I was able to recover it manually from my backup mirror disk. And I don't believe that FFS with just the timestamp without reading the content would have detected this corruption at the source to automatically suggest the wise choice to prefer the old backup of the corrupted file.
If I had to synchronize such a thing I'm afraid the corrupted file would overwrite a healthy backup.

In short, if between 2 files (source and destination) never modified (seen by date) one of them had a checksum different from the first or last synchronization, it would be useful for FFS to be able to detect it and warn of a possible corruption by preferring the version answering exactly to the last checksum. See to automate this function.

I will still offer myself this software very well done so far to support the project. Thanks again for your intervention.

[Liriz]

A list of the checksum of all the files copied / synchronized in the database could allow FFS to recheck the integrity of the pairs of unmodified files whose checksum differs during future synchronizations.

And also to be able to back up databases by location profiles elsewhere than at the root of the disks. For safety, for bulkiness, and for the sake of not seeing them lying around. :)

There you have it, to put it another way. Long live FFS!

[xCSxXenon]

There was another thread, I believe, that Zenju explained this feature is limited since FFS is designed to be used without having installed on an external location. I think checksums cause some issue with that element

[Plerry]

@xCSxXenon
That's the reason for providing the link in my first reply on this topic.

[xCSxXenon]

@Plerry, you're too good!