Local state larger than global shouldn’t be possible, right? I suspect this is caused by mixing negated and normal ignore patterns, e.g.
!/folder/*.txt
/folder
however I haven’t been able to reproduce the problem in my test environment despite numerous attempts.
The main problem with this situation is that the only way to get things back to normal seems to be through performing a full database reset .
Has anyone got any ideas what exactly can be going on here? I can provide debug information, etc. but I doubt it will be of any use without a reliable way to reproduce the problem at will…
Probably you’ve tickled a bug, but on that note, keep in mind those numbers are a counter updated in a fairly complicated manner and doesn’t reflect a “scan” of the database as such. The counters get dropped and recalculated from the actual database contents every 90 days or so, and there’s an env var you can set to force an earlier recalculation. Maybe set that for one startup and see if the numbers change.
Do you mean STRECHECKDBEVERY? Unfortunately, it doesn’t make any difference . I’ve tried doing --reset-deltas too but also to no effect. That’s why I believe that a database reset is the only way to fix things here.
That was quick! And I was just about to perform a reset…
There’s one issue though. Two folders are affected at the moment. One of them contains a lot of personal information but the other one does not. Would it be a problem if I removed all other folders first, and only shared the DB with the the second folder left in there?
There are two files that the database isn’t consistent about whether they’re deleted or not. Since the mismatch is two files this seems related, but I didn’t dig into it at all. The names of the files made me want to nope out of this completely:
The explanation is rather simple though. These are remnants of https://forum.syncthing.net/t/is-there-any-danger-in-allowing-to-synchronise-the-folder-marker/19067 which I were going to take a step back on but haven’t managed to do yet (as this requires access to all devices at once which I actually have at the very moment so I may just do it right now). The .stversions is just file versioning set on another device using a custom folder path so that it can sync across all devices. No other devices have versioning enabled.
Ideally, the folder structure should look something like
What’s interesting though is that I weren’t suspecting these two files to be the culprit, especially since they do exist in the folder physically. I’ll now try revert the .stfolder sync, reset everything back to normal and see whether the problem comes back.
Thank you for looking into the database anyway .
Edit:
Just for the record though, having reset the database, Syncthing did manage to properly recognise the two files as local additions.
I’ve got yet another example, this time without any .stfolder shenanigans.
Below is a Receive Only folder marked as “Local Additions”.
However, pressing the “Revert Local Additions” button actually adds the local file directory to the global state (!!!).
This is a part of a very large setup, so sharing the database would be complicated, but I personally think that this whole problem may be related to https://github.com/syncthing/syncthing/issues/8735 also.
Details to be figured out I guess, but I’m not surprised to see mismatches in directory count when there are un-ignore patterns matching files deep in the hierarchy.
.
. I’ve tried doing 
.
.
