Today I had one node (say node “A”) that had an out of sync status, due to a (supposed) discrepancy between local state and remote state (wanting to download some files).
However, all other nodes (one of them being actively connected) seemed to agree with the local state of node A (the files that the latter wants to download existed once, but are long gone from the whole ecosystem). So, it seems that the global state of node A is simply incorrect; meaning it would never receive the “desired” files; making it out of sync forever.
I worked around the issue by removing the folder from node A, after which it successfully re-synced-up with the other nodes. Luckily there were just 4 files (a mere 50Kb) that had to be synced.
So here are my 2 questions:
Any idea how this situation can emerge (e.g. anything I could have done to prevent it)?
Is there a way to “reset” a global state of a node (e.g. in the case there was much more content, making my workaround too tedious)?
Too bad I did not make any screenshots. I’ll post them here if it ever happens again (it happened once or twice before with my setup).
Unclear why that would happen, but a soft way to maybe fix it in current Syncthing (0.4.17 and newer) may be syncthing -reset-deltas which will force a full database resync with the other devices.
Thanks for your answer, but I already know this and did it just a second ago.
Maybe there could be a commandline interface or some kind of hidden special menu for these options!?
Like syncthing-android has for resetting the database.
Sorry if I caused you any “head breakers” over this @calmh…
Apparently there was a rogue Android node in my pool (it contained the files and was, is often, offline), that only synced with the device showing the “issue” (between quotes as it Syncthing was right, It was me that made the mistake).
Thank you so much for your very active development (and communication!)!
The option was added a couple of days ago because I needed it for development. It’s unclear if it had any impact on this issue, and it shouldn’t be generally needed by anyone, really. So I think better to not have it very prominent until it’s clear it’s needed, and even then it’s better to fix the bug that requires it.