FreeFileSync restores deleted files at the target directory

Get help for specific problems
Posts: 9
Joined: 2 Feb 2023

HansHans

When I delete a file in one directory (I call it source here), it will be restored in the syncing process from the other directory (I call it target here).
Similar problem:
When I move a file of the source directory to a subdirectory below the source directory and start the syncing process, with the target directory, then the this moved file is restored from the target directory to the source directory and additionally the moved file in the subdirectory of the source directory is copied to the subdirectory of the target directory.
The result is, that I have identically the moved file twice in the source directory and its subdirectory and twice in the target directory and its subdirectory.
Or to make the long story short: The file deleted in any of the directories (source or target) will be restored from its counterpart on the other side.

How can I get the files deleted on one side be also deleted on the other side.

And moreover: I do not really understand, how FreeFileSync does its recognition, that I intentionally had deleted a file and that it should not be restored? Can someone explain it?
Posts: 9
Joined: 2 Feb 2023

HansHans

Just to add my Sychronisation-Settings, I include this screenshot
Attachments
FreeFileSyncEinstellungen.jpg
FreeFileSyncEinstellungen.jpg (66.55 KiB) Viewed 909 times
User avatar
Posts: 3614
Joined: 11 Jun 2019

xCSxXenon

https://freefilesync.org/manual.php?topic=synchronization-settings
Sounds like you might be using a filesystem that doesn't have stable IDs
Posts: 9
Joined: 2 Feb 2023

HansHans

I find a file named sync.ffs_db in each of the directories.
Suprising point is that one of these files does exist, but has no entries in the properties: "created","last modified" and "last access", while the other have these properties filled.
What does that mean?

The distant directory ist a SMB-directory mounted in windows with drive letter.
Posts: 10
Joined: 1 Oct 2018

harryytm

In filesystem like NTFS, each file have a file ID, reside inside the MFT file record of each file, no matter how you change or move the file on the same NTFS volume, the file ID would remain the same.

FreeFileSync use the file ID provided by the filesystem and store it into the database file sync.ffs_db, to trace file move or rename, if you have read the manual of FreeFileSync carefully, there is clear explanation of how this feature work and its limitations.

>>> Synchronization Settings <<<
User avatar
Site Admin
Posts: 7055
Joined: 9 Dec 2007

Zenju

In filesystem like NTFS, each file have a file ID, reside inside the MFT file record of each file, no matter how you change or move the file on the same NTFS volume, the file ID would remain the same.

FreeFileSync use the file ID provided by the filesystem and store it into the database file sync.ffs_db, to trace file move or rename, if you have read the manual of FreeFileSync carefully, there is clear explanation of how this feature work and its limitations.

>>> Synchronization Settings <<< harryytm, 24 Jan 2024, 05:32
File IDs are not relevant to the OP's problem. Detection and propagation of ordinary CRUD operations only requires sync.ffs_db files. This will start working with the second sync, i.e. when DB files from previous sync are available.