What does .sync.fs_db store?

[IsaacD]

Hi,

I use FreeFileSync to sync my files on two different computers periodically. The way I do it is I mount the filesystem of one onto a directory in the other (via sshfs) and then sync the home directories.

So my question is, what is stored in the sync.fs_db file?

Here is the reason I'm curious: I think what is stored there is a sort of snapshot of the filesystem at the time of a sync so that at the next sync the program can tell which side has changed since last time. But I worry that if I initiate the sync from computer 1 one time and then from computer 2 the next time, this may mess things up. Perhaps the database file on computer 2 will be older (since I haven't initiated the synced from there in a long time) and it will judge its own host (computer 2) to be more updated than 1.

In other words, say you create a file on computer 1 called /example and you initiate a sync with computer 2. The database file on computer 1 knows about this file, the one on computer 2 doesn't (since the last sync in that direction was a long time ago). Now you decide to move this file into a folder /scenario/example on computer 1. Then you initiate a sync from computer 2. The database file there sees this /example file only on its own computer and sees the moved version only on the other. So it decides to create both/example and /scenario/example on both computers.

Anyway, that's the situation I'm trying to ward off. So I thought that perhaps as a way to solve this, I should have a script automatically copy the sync.fs_db file right after every sync, from the computer that initiated the sync, to the other one. That way both computers will have the same sync.fs_db. Would my solution work?

[xCSxXenon]

FFS creates a db file in each side when using a two-way sync

[IsaacD]

Oh, I see. So they're identical anyway and no such issue could arise.

Thank you!

[Plerry]

No, the db-files at either side are not identical.
As stated here, FFS (also) stores file IDs in the db and uses those for detecting moved or renamed files.
File IDs differ per location, so the db will differ per location.

So, the question to Zenju (the developer) is:
Is it a problem if multiple sync counter-locations run two-way syncs to one and the same (e.g. network) location?
If not, does FFS per location create a separate db for each different sync counter-location, or is the data for all sync counter-locations stored in one and the same database.

[Zenju]

Is it a problem if multiple sync counter-locations run two-way syncs to one and the same (e.g. network) location?

This scenario is fine as long as "LockDirectoriesDuringSync" (a.k.a. sync.ffs_lock) is enabled, which is the default.

If not, does FFS per location create a separate db for each different sync counter-location, or is the data for all sync counter-locations stored in one and the same database.

Each db file contains data (-pieces) related to all other sync locations it has been synced with. The information is folder-pair specific and is split up and distributed among the two sync.ffs_db files involved.

[IsaacD]

So suppose I have three locations A, B and C. I place files in A and sync them with B. Then I delete a file in B before syncing B and C. If I then sync A and C, the deleted file will reappear in C. Is there a way to avoid this?

To make things clear, these are the steps:

1. Create a directory, A, with files
2. Sync A with B
3. Delete a file in B
4. Sync B and C
5. Sync A and C

Since the sync.ffs_db files are not identical in synced directories, we cannot just have a script check the db files and only allow a sync if they match up. So would there be a way to avoid this kind of situation?

Thank you,
Isaac

[Plerry]

The above reads as a fairly illogical way of running syncs.
The more logical approach is to run all syncs versus a single "central" location, e.g. C.
So, you would sync A<=>C and B<=>C, but not also A<=>B

But, taking your example:
As you created A in step 1, there is no previous step 5 A<=>C sync and thus no corresponding db file data.
Hence, this first time you run step 5 will (re)create the file (deleted in B in step 3) in C.
However, if A, B and C would have been fully in sync (per previous syncs, with actual db files in place)
and you would then perform step 3, 4 and 5, the file deleted form B in step 3 would also be deleted from C in step 4 and ultimately also be deleted from A in step 5.