The solution? The sync directions should be determined based on 'changes' compared to the last sync, in the exact same way that 'two way' operates, by using a database file. Additionally there's the issue where a file on the source side is renamed: without a database this change cannot be detected, so 'update' needlessly copies a duplicate file to the backup location. Unfortunately this is precisely what the results-category based 'update' does. On the other hand, photos deleted on the backup, should *not* get them copied over again during the next sync: The user is just cleaning up unwanted photos. The user is just making free space for new photos.

When photos on the smartphone are deleted, they should *not* be deleted on the backup, obviously. But these two should get different handling: The most common 'update' case is making a copy of photos from a smartphone to some backup location. Thous it's unable to distinguish whether a new file was created on the source, or if an old file was deleted on the target. 'Update' was making it's decision based on the result categories after comparison. Of the three sync variants that FreeFileSync offers by default (two way, mirror, update) it always bothered me that 'update' wasn't as fundamental and useful as the other two.Īfter meditating on the issue, I think I found out why.

Sync-cfg.png (40.73 KiB) Viewed 2834 times

FreeFileSync 13.0 instaling