Dear developers,
I faced with a few new cases “Out of sync” problem. I have updated almost all my nodes up to version 1.17.0 and I expected that all of them will be in “Up to date” state. However, some strange things are happening that I try to describe below.
There are two nodes with a few common folders. One of them has simple ignore patterns to exclude temporary files like *.pyc, ~, etc. There are no problem before with sync state (version 1.15.1). I’ve updated them one by one with a long delay, not simultaneously. As a result I have alot out of sync items, but all of this items are folders! There are no files among them!
Another folder are shared among at least tree nodes (A,B,C) and has a complex ignore patterns which differ on different sides. Node A downloads all files from all nodes. Node C introduce a subfolder some time ago and now it is offline. So, node A has the subfolder and can share it. Node B ignores this subfolder but items from this subfolder are included in the out of sync list from the previous picture. Why node B try to sync items, ignored by himself?
To clarify I add the rest request form the node B.
Just to have it mentioned: Indexes are resent on upgrade to v1.17.0. So temporarily it’s expected that remotes are shown as “syncing”. Apparently it’s not just temporary here, and indeed shouldn’t be (sigh).
The info shows a file that is ignored locally, and exists on a device IZ3E6JL. That alone doesn’t mean much: Can you please post screenshots of both the remote device and the folder from both devices where there is a discrepancy - thanks.
Bingo! Device A (IZ3E6JL) is Out of Sync. Some files are really absent but I can not understand why… It may be a bug of previous version or something else. But! From the side of the node B it does not matter if node A have some problems with the subfolder as node B do not want to download it. In fact, node A reports that the file is not available (see attached txt, the previous one was for the file which did not cause the problem, sorry).
You have a lot of failed items - what do the errors say there? (The screenshot you showed is the list of out-of-sync items, not of the errors, that’s the other link). Looking at the out-of-sync items I expect you ignored .git (good) and then deleted a parent directory on a remote. Now Syncthing should remove .git but can’t, because it’s ignored. See the (?d) prefix: Ignoring Files — Syncthing v1 documentation
Dear Simon, it seems I confuse you by mixing two different cases in one topic, I’m sorry for that. Let’s skip the case 2 with three nodes, I will try to reproduce it later in details.
Regarding the first case the situation is still the same. I have a lot out of sync items that seems to synced in fact…
There are tree device - A,B (1.17.0) and C (1.7.1). Devices A and B have been upgraded from the version 1.15.1 one by one with a long delay, so the indexes were resent firstly from A (1.17.0) to B (1.15.1) and then back from B (1.17.0) to A (1.17.0). Everything fine on the device B and all folders are Up to Date. Device C appeared later.
Сonsider one file that is in out of sync list on device A:
U2S3F75-A.txt (1.1 KB)
The same one on the device C:
4F22O43-C.txt (1.1 KB)
Why A do not see the file on B while C see both nodes perfectly?
One additional strange thing - parent folder on A became invalid:
distr.txt (1.1 KB)
To be honestly “ignored” and “invalid” flags newer works correctly for folders.
The infos from the rest api are from different files, so I can’t actually compare them. Also I assume you are talking about remote out of sync only, not folders - full screenshots are always a good thing to answer such (and many other questions) automatically. And as there are ignored items included, please also specify the ignore patterns (e.g. the “distr” dir is ignored, while you say you have temp file ignores, etc).
It all looks identical and well. That’s consistent with the missing indexes problems. We fixed a major cause of that in v1.17.0, which you are already on (pity). There has been another improvement in this area in v1.18.0, however I haven’t yet thought of a scenario where it can lead to such a problem that you experience.
In any case unless you can reproduce it and/or get model debug logging on it, there’s unfortunately no way to know how/why it happened.
To resolve the problem, it should be enough to start syncthing with --reset-deltas once on device A.
Dear Simon,
This problem appears exactly after upgrading to v1.17.0… But, it’s possible that v1.17.0 just reveal the problem that was exist before. Anyway, I would not like to use --reset-deltas as I read some messages here that it resulted in uncontrolled file deletion and I hope that new fixes in v1.18.0 could resolve it smoothly.
At the same time I will try to reproduce this situation together with another one with ignored files as soon as I have a little time and three devices in one time. What kind of debug logging modules I should enable?
Definitely not - --reset-deltas is totally save. It’s just “inefficient”, in that devices need to exchange all index info again. The index info itself is not touched by this option. A long time ago that was the default behaviour on every new connection
If you can reproduce it, logs with model,db debug logging would be good. However I do not advice to enable those facilities and “wait for a reproducer”. They are extremely verbose.
I have the same problem, it may have been caused by the 1.17.0 upgrade but I’m not sure, maybe I just didn’t notice it earlier. If I can help by sharing screenshots and/or logs, let me know.
