sync.ffs_db incompatible

[emptythevoid]

We use FFS to keep a large folder synchronized two-way between about 7 laptops and a central samba server. This has generally worked well. However within the past few days, someone will try to sync and get a warning that the sync.ffs_db is incompatible. The only other time I've seen this was when we had people still on version 9. We're all currently on 10.22 and 10.23. It's very sporadic, so I don't know what is causing it. Today, someone synced, and the sync.ffs_db was a little over 1 meg. Later, someone else synced and got the incompatibility error. We had her ignore it and the new sync.ffs_db file was under 4kb.

We've got a lot of people working from home over iffy hotspots and VPN connections, so I'm thinking it's something due to crappy internet. However there doesn't seem to be any issue with the sync completing (no error messages, at least). It only seems to be a random problem when someone later tries to sync. We've not been able to replicate this problem on-demand.

Does anyone have any suggestions or thoughts on this?

[emptythevoid]

Screenshot at 2020-05-05 13-48-57.jpg (86.23 KiB) Viewed 1300 times

This is what it looks like when the error appears, for whatever this is worth.

H:\ is our samba server.

[Zenju]

I've improved the error message to make it clear what's going on (either data corruption or an old FFS version in the mix): https://www.mediafire.com/file/j83gmoecb55iks5/FreeFileSync_10.24_%5BBeta%5D_Windows_Setup.exe

[emptythevoid]

Aww, thank you! I'll let my manager know that we've got something to try.

I'd be satisfied to find out that it was somehow data corruption that was breaking it. What's weird is that the syncs that I can personally account for *seem* to complete without error. That said, my sample size is small and I've got many users all syncing, so I might be missing something. I'll report back. I appreciate your help!

[Zenju]

What's weird is that the syncs that I can personally account for *seem* to complete without error.

When the database fails to load and this is ignored, FFS falls back to "copy newer files both ways". This might be the sync direction you want anyway in some cases. In other cases it's wrong. E.g. if a file was deleted it will be copied back or if a newer file was overwritten by an older version, this will also be undone.

[emptythevoid]

That's exactly the behavior we experienced. It's relieving to hear you explain it.

When a sync completes, the client writes out the database as a last step, correct? I'm assuming that my users aren't getting an error message during this last step. If that's the case, is it possible for the sync process to check on the database file it just wrote in order to make sure it isn't corrupted, and if so, correct it? Maybe it already does and the problem we're experiencing lies elsewhere. I'm just wondering why we seem to only find a (presumably) corrupted database file only when the next sync occurs, and not when the current sync is completing.

[Zenju]

When a sync completes, the client writes out the database as a last step, correct? I'm assuming that my users aren't getting an error message during this last step.

The DB is updated after a folder pair has been synced. Any errors are reported, and saving is done "transactionally" by writing to a temporary file first. So data corruption isn't very likely, unless there is a hardware defect of some kind.

[emptythevoid]

So just this morning, I got a report of someone who's VPN lost connection mid-sync. We were able to get her to re-do the sync before anyone else, so problems were minimal, and no one has gotten a database error. I've been assuming this is what was happening with the previous database problems, but no one had reported any disconnect errors. We'll keep checking.

I'm sure there's documentation that explains this, but if the user manually stops the sync mid-way through (using the stop button, not pulling the plug or shutting down the computer), the database file should still be OK for everyone else, yeah?

[Zenju]

Except for hardware defects where the DB file is altered in some way *after* it has been written successfully there is basically no way for it to become corrupt.

[emptythevoid]

Gotcha. Thank you so much for taking the time to help me. It's *highly* appreciated from everyone here. I'll report back if we find out anything interesting.