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?
FreeFileSync restores deleted files at the target directory
- Posts: 9
- Joined: 2 Feb 2023
- Posts: 9
- Joined: 2 Feb 2023
Just to add my Sychronisation-Settings, I include this screenshot
- Attachments
-
- FreeFileSyncEinstellungen.jpg (66.55 KiB) Viewed 1060 times
- Posts: 4055
- Joined: 11 Jun 2019
https://freefilesync.org/manual.php?topic=synchronization-settings
Sounds like you might be using a filesystem that doesn't have stable IDs
Sounds like you might be using a filesystem that doesn't have stable IDs
- Site Admin
- Posts: 7212
- Joined: 9 Dec 2007
- Posts: 9
- Joined: 2 Feb 2023
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.
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
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 <<<
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 <<<
- Site Admin
- Posts: 7212
- Joined: 9 Dec 2007
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.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