Hi
I have a suggestion that I think can be beneficial for a lot of users.
One of the key usages of FFS in my mind is to perform backups. The backups usually have these "features":
* Are big
* Are stable (i.e. they don't change on the backup site)
* Are on another machine
This means that if you want to have a comparison check (and not only file+size) you will need to verify a large amount of data (big backup) on a slow connection (remote machine), and this verification is usually useless, since data doesn't change on the remote machine. In addition, if you are on a pay-per-use connection, you will waste a lot of bandwidth.
(of course data can change on the local machine, but this is on the same machine so quite fast)
I thought it would be great to have some way to improve this scenario, for instance have a "by hash" comparison, then give the user the possibility to cache the hashes on one folder (e.g. in the sync.ffs_db file, or better in a dedicated file) to avoid checking it every time. If the user thinks the remote backup has been changed he can delete the cache, and the comparison will be complete. If on the other hand it wasn't modified then the cached content will be verified against.
What do you think?
Feature request: avoid complete comparison for remote locations
- Posts: 2
- Joined: 9 Sep 2026
-
- Posts: 3020
- Joined: 22 Aug 2012
viewtopic.php?t=11337#p43674
Also follow the links given in that reply.
Also follow the links given in that reply.
- Posts: 2
- Joined: 9 Sep 2026
Yes, the assumptions in the links are always correct (you need to transfer the whole files if you want to compite the hash)
BUT... If the remote location is a backup one (so it is usually accessed only through FFS) then files do not change on the remote. So from the second sync you can decide that you either trust nobody modified the files manually on remote, and so use the hashes, or do not trust it, so delete the db and perform a full Sync again.
I agree that a hashed comparison is useless if you can't cache the values (direct comparison is better), but as you saw caching is considered a useful feature (it was requested multiple times by multiple people in time)
BTW sorry, I didn't see the older posts, otherwise I wouldn't have opened a new one
- Posts: 4949
- Joined: 11 Jun 2019
Which is why other programs to do this were mentioned. This feature could certainly be implemented in FFS, but so could any feature ever because it's just code. It has been decided to be out-of-scope as it falls outside what FFS was designed/intended to do, which is make sure the locations provided are in sync, not that one location is in sync with a list of hashesit was requested multiple times by multiple people in time fra87, 10 Sep 2026, 10:58
-
- Posts: 3020
- Joined: 22 Aug 2012
Hashes are commonly used to determine if files have become corrupted;
file size and date has remained unchanged, but its content has changed.
The potential of file corruption in between syncs exists both in the source and the destination/backup location. So, if the purpose of using hashes is to detect file corruption, it is weird to only do so at the source-side but not at the destination/backup side.
Using hashes to determine which files have changed (not been corrupted) at the source side since the last sync, and need to be synced to the destination/backup side is an effective, but inefficient method.
FreeFileSync (FFS) uses file-IDs for that purpose, comparing the stored file-IDs per the end of the previous sync with the present file-ID of a file.
This method is much faster than loading a file, calculating its hash and then comparing that to a hash value of that file at the end of a previous sync.
Besides that, a source location to destination/backup location sync (e.g. Mirror sync) is just one of the types of syncs FFS can perform. Those other methods generally still require both sides to be involved in a comparison. Introduction of a "feature" that is only useful for one of FFS types of syncs makes little sense.
Next to that, FFS may, for several reasons, just as well be executed on another machine than your source location. To calculate/verify the hashes of files in the source location, those files would still need to be downloaded to the machine executing FFS.
> (it was requested multiple times by multiple people in time)
That does not make it a useful feature for FreeFileSync.
It just illustrates that "multiple people in time" have problems comprehending the finesses in this matter.
file size and date has remained unchanged, but its content has changed.
The potential of file corruption in between syncs exists both in the source and the destination/backup location. So, if the purpose of using hashes is to detect file corruption, it is weird to only do so at the source-side but not at the destination/backup side.
Using hashes to determine which files have changed (not been corrupted) at the source side since the last sync, and need to be synced to the destination/backup side is an effective, but inefficient method.
FreeFileSync (FFS) uses file-IDs for that purpose, comparing the stored file-IDs per the end of the previous sync with the present file-ID of a file.
This method is much faster than loading a file, calculating its hash and then comparing that to a hash value of that file at the end of a previous sync.
Besides that, a source location to destination/backup location sync (e.g. Mirror sync) is just one of the types of syncs FFS can perform. Those other methods generally still require both sides to be involved in a comparison. Introduction of a "feature" that is only useful for one of FFS types of syncs makes little sense.
Next to that, FFS may, for several reasons, just as well be executed on another machine than your source location. To calculate/verify the hashes of files in the source location, those files would still need to be downloaded to the machine executing FFS.
> (it was requested multiple times by multiple people in time)
That does not make it a useful feature for FreeFileSync.
It just illustrates that "multiple people in time" have problems comprehending the finesses in this matter.