Ignored folder is out of sync

Support
1

Hi!

First of all, thanks for the great software. I have dozens of nodes in sync on different platforms and most of the time Syncthing is working flawlessly.

Recently some of the nodes got stuck in “Syncing” state. Lets say, A is the master node (send only) for some folder, and B, C and D are the receive-only nodes. All of these have the __pycache__ as the ignore pattern. Some time ago on D the ignore patterns were cleared (and likely the folder type was temporarily changed to Send and receive) and then __pycache__ was added back. Since then on B the __pycache__ subfolder is shown as out of sync, while on C it’s ok.

out-of-sync
out-of-sync896×388 4.38 KB

I’ve already recreated from scratch the syncthing config on D, so the device ID changed and the Mod. Device column on the screenshot above shows the old device ID instead of its name.

The problem is very similar to the one described here: Syncthing "stuck" syncing because of device that doesn't exist?

That topic is closed as it was reported that it’s fixed in 1.9.0. I’ve updated all nodes to 1.10.0 and did a DB reset, but the problem persists.

What are the steps to make Syncthing forget the out-of-sync ignored folder completely?

1 Like
2

I had a similar process these days. I have a .sync subfolder in almost all peers and this folder is entered in all IgnoreLists and normally there are no problems with it.

However, on a Windows 10 computer I suddenly had the response in the GUI that the synchronization of this folder and its contents in 2 peers had failed. I checked the directory names, folder permissions, IgnoreList for errors, etc. I found nothing. Only in 2 of around 200 peers in which this .sync folder exists, there were these abnormalities, and only on this device. Even disconnecting the peers and reconnecting did not change anything.

I no longer knew how to fix it. By chance, however, it had taken care of itself. These two peers were already connected to 6 devices and each added a 7th device. After that, the problem was resolved and it has not occurred since.

What explanations could there be for this?

3

Bump. No ideas? Still can’t force Syncthing to completely ignore these __pycache__ folders.

4

Maybe wait until tomorrow, to use v1.11.

5

Updated to 1.11.1. Still the same problem.

6

Can you get the output for that folder and path of https://docs.syncthing.net/rest/db-file-get.html please. Both on a device that shows the problem, and one that is ok.

7

Sure. Using the same naming as in the first post:

  • A is the send-only node
  • B is out of sync (as seen on A)
  • C is synced

Here are the details for the __pycache__ path:

I see that B has "ignored": false for the __pycache__ path, but it’s there in the ignore patterns.

8

I’m allowed only 2 links per post, so С goes here:

9

Ah, so we are talking out-of-sync on the remote devices, not the folders? Screenshots would help by preventing such misinterpretations on my side :wink:

Can you please state the pairings of A-C to their respective device ID (just the first block).

Just increased your trust level, hopefully no more obstacles like that now.

10

Or actually it might already be clear what the issue is with the existing info: Device A knows about a device QGWG5DH that has “pycache” not ignored. Device B does not have the file at all (ignored or not) and doesn’t know about this device QGWG5DH, thus doesn’t update itself. That’s why from the point of view of A it is correct, that B is out of sync. That typically happens if QGWG5DH is offline or not connected to B at all.

11

Thanks a lot! The device QGWG5DH is none of the above and it was the cause. Just added the __pycache__ path as ignore pattern to it and everything is in sync now.

Still don’t understand though, why B was displayed as out of sync, while C was in sync.

12

That’s implementation detail: The dir existed on C before it was ignored. Thus when it got ignored, it sent an update to everyone telling them that it now ignores the file. On B the dir never existed, so it never announced anything about it. Thus A know that C ignores it, but for B it expected it to either get the file from QGWG5DH or announce it ignores the file as well.

13

But B has that path and it’s ignored. Why does it matter whether the path existed when it was added as ignore pattern?

14

That’s part of the implementation detail xD :
When scanning new local items, we ignore ignored paths. And because from the point of view of B everyone else either didn’t have the dir or ignored it, it didn’t pull it either. So it just didn’t have and or announce it. However C having first announced it as non-ignored, needed to announce it again as ignored. Otherwise other device will try to get the previously non-ignored file from it.

15

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.