Try to understand sync.ffs_db in two way sync.

Discuss new features and functions
Posts: 41
Joined: 10 Jul 2016

JustAnotherUser

Hi all,

after years I'm going to use FreeFileSync again and for long term and surely I will donate then.

Edit:
I already decided to donate and did this right now (e-mail: mr*l@web.de)

Currently I try to understand the concept of the 'sync.ffs_db' files for two way syncs.

I found some statements in other threads in this forum from Plerry and Zenju:

@Zenju wrote:
Think of the sync.ffs_db file as a marker for a data location. FFS distinguishes folders by this file, so if you copy it, FFS will see both locations that contain the very same sync.ffs_db file as if they were the same.
@Plerry wrote:
The sync.ffs_db file contains info on the status per the end of the last sync.
FreeFileSync (FFS) will not sync the sync.ffs_db file(s).
So as far as I understand a 'sync.ffs_db' contains exact information about all files and folders and their necessary attributes of the base folder to where they belong per the end of the last sync.
And each 'sync.ffs_db' stays in it's base folder and won't be synchronized by FFS.

Sounds great and I can follow the idea.

But @Zenju also wrote:
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.
What does this mean?
I can't follow this idea/necessarity why a 'sync.ffs_db' not only contains infos about it's own location/base folder.
Whatfor does it need information about the other location(s) it has been synced with and what information is this?

I would be very grateful if someone could enlighten me. I would just like to understand it to be able to trust the concept. It is certainly not a secret.
User avatar
Posts: 2291
Joined: 22 Aug 2012

Plerry

What does this mean?
I can't follow this idea/necessarity why a 'sync.ffs_db' not only contains infos about it's own location/base folder.
Each base-location folder does only have a single 'sync.ffs_db' file.
If base location D (arbitrary) is synced (via different FFS-syncs) with respectively base locations E, F and G, then D will comprise a single 'sync.ffs_db' file with info on the status of D at the end of the last FFS sync of D with E, the status of D at the end of the last FFS sync of D with F and the status of D at the end of the last FFS sync of D with G.
If a new FFS sync between D and F is run, FFS determines the changes that occurred in D by comparing the actual status of D to the one recorded in the 'sync.ffs_db' in D for the sync between D and F, and thus knows what has changed in D (since the last sync with F). Similarly, FFS determines the changes that occurred in F by comparing the actual status of F to the one recorded in the 'sync.ffs_db' in F for the sync between D and F. Based on the concluded changes, FFS then determines sync actions and potential re-names.
Posts: 41
Joined: 10 Jul 2016

JustAnotherUser

Ok, I understand that and I am convinced that it makes sense.

If only so that FFS can judge whether a file that exists only on D when syncing D with E was added to D, or possibly deleted by a sync of E with F on E.

BTW: All these formulations alone twist your brain.... :-)

Thx. in advance Plerry!
User avatar
Site Admin
Posts: 7058
Joined: 9 Dec 2007

Zenju

Just to add to Plerry's correct explanations: The sync.ffs_db is probably better thought of as an archive instead of a simple file. It contains many versions of state, one for each folder location it has come into contact with during sync.
Posts: 41
Joined: 10 Jul 2016

JustAnotherUser

Thank you @Zenju.