Inspect/cleanup database content.

[echtatze]

Hi.
As far as I remember a database file can hold info of more than one sync-pair.
In a different thread you wrote this:
"By each database having their own unique identifier, each sync-pair can be easily identified, just as if you had multiple database files."

This means that with each additional sync-pair the size of the database file can/will grow.
Is there a possibility to get info about the content (means the 'pairs/peers') of such a database file?
And additionally is there a possibility to remove a 'pair/peer' from a database file?

Backgroud:
Imagine the situation that one syncronizes data stored on a USB thumbdrive with three PCs.
So the database on the stick is as huge as all three databases on the PCs together, right?
If I now do not use one of that PCs any more, the info about its pair/peer in the database is still in and will stay there forever, or?

And during writing this I have one more question which belongs to the unique ID of a database:
How is this ID build? Does it belong to the machinenname and/or its MAC adress?
Or is it just something like a GUID?

Thanks in advance!

[Zenju]

Yes, the database file does not shrink by itself if you choose to not sync against a particular folder anymore. This might be obvious, because FFS cannot know when and if at all you will sync again.

If the database file grows too big (I don't think this will ever be a problem, except for extreme cases since the database files are highly compressed) you can delete them and have them rebuilt automatically during next syncs which will make FFS behave like on the first sync.

[echtatze]

Today I read our small discussion again, to recall your strategy regarding the database files.

I'm still interested in how this ID is build.
Does it belong to the machinenname and/or its MAC adress?
Or is it just something like a GUID?
Or any other algorithm?

I'm asking because I also plan to sync to different clonded VMs.

Would be nice if you explain that to me, I think it's not a secret, or?

Thanks in advance!

[Zenju]

The database files use a GUID that is newly created during each sync. Therefore it's safe to sync against cloned VMs: After syncing with the first clone instance for the first time, the other clone instance implicitly loses the connection and behaves like it never participated in any synchronization.

[echtatze]

Now I'm confused, sorry.
If understand a GUID as a nearly random value.
So if the GUID is newly created on every sync, how does FFS detect the proper sync-pair in the database if there are multiple sync-pairs stored in it?

[echtatze]

If you find time, please try to explain it to me.

[JustAnotherUser]

As far as I understand so far, the GUID, which is the unique ID of each database file, is created when a database file is first created and not every time the base folder is synchronized, right?

[JustAnotherUser]

Or am I wrong here?

[JustAnotherUser]

@Zenju: Would be nice, if you could clarify this.