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.
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.
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.
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.
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.