Folder stuck in sync and non-matching local and global states

Support
1

There are three devices - A, B, and C. The folder is shared between A and B (as Send & Receive on both), and between B and C (as Receive Only on the latter). There are ignore patterns involved, but they are exactly the same on all the devices.

Device A (local and global states match)

1
1712×370 28.4 KB

Device B (local and global states differ)

3
3712×367 28.3 KB

Device C (local and global states match, but differ from Device A)

2
2712×370 28 KB

As you can see, everything is marked as “Up to Date”. However, there is a folder stuck in sync between Device B and C.

4
4708×168 14.8 KB

5
51061×325 9.95 KB

The thing is that the folder itself does in fact exist on all three devices. It is still seemingly stuck in sync between Device B and C though. I have encountered this kind of a problem quite a few times recently, but this time this has happened right after upgrading to Syncthing v1.14.0 and resetting the databases at the same time.

The current state is probably as clean as I can get it, so I would be interested in finding the culprit. Unfortunately, I have no debug logs that could shed more light on how the folder has come to this situation. I will also try to query the REST API tomorrow to get more information on the folder itself.

Do you have any idea what can cause this kind of a mismatch?

2

I have queried the REST API for the folder.

Device A.txt (844 Bytes) Device B.txt (907 Bytes) Device C.txt (842 Bytes)

1
11490×839 59.5 KB

I can see that the folder is “ignored” on two devices, but not “ignored” on one of them. As I said before, the ignore patterns are exactly the same. I’m assuming that the problem are patterns like the ones mentioned in https://forum.syncthing.net/t/irreversible-local-additions-in-newly-added-ro-folders/16193, i.e.

!folder1/*/folder2
folder1/

The folder that is seemingly stuck in sync would be covered by the * here. Are these ignore patterns inherently problematic or am I doing something wrong?

3

Which device is 7LDIBZ4? Also if you query /rest/debug/file with the same parameters there’s one more potentially valuable piece of info (the full global list).

Is the folder shared between A and C?

4

The folder is not shared between A and C. It is shared only between A and B, and then between B and C. The sync is only “stuck” on B, trying to send the folder to C. Interestingly, the “Mod. Device” is reported as A.

Here you are.

1
11529×899 68.4 KB

5

The missing connection from A to C is an important clue. One part of the problem is definitely the puller not taking care of parents of un-ignored items (as in e.g. folder1/foo in relation to your ignore pattern !folder1/*/folder2), while the scanner does. However the debug output you posted also shows that C actually knows about the “newer ignored” file from B and should indeed pull it (nice to have the info at a glance in the screenshot - thanks!). So there’s some more to it than just the puller awareness. In any case this is something I can work with (for fixing the puller stuff and trying to repro). Not right now though - if I forget about it feel free to ping here after some time :wink:

1 Like
6

No problem. Please let me know if you need more information. I will leave the folders in this state for now, as this doesn’t seem to impact the actual synchronisation in any way.

Just for clarification, the folder in question does physically exist on all three devices. Its subfolders also keep being synced properly. It is only Syncthing that keeps complaining about it :upside_down_face:.

I find it useful too :smirk:. For the record, this is WinMerge, an open source (GPL) program for text data comparison. It is Windows only though.

7

That’s because there’s a work-around independent of ignores in the puller: We create missing parent directories when encountering a valid file to pull.

1 Like
8

Just a quick update, as I have noticed that the folder is now listed as “Local Additions” on Device C.

1
1709×578 43.8 KB

Trying to revert local changes leads to:

Reverting folder 0x1a90320
Revert: directory has been deleted on a remote device but is not empty; the contents are probably ignored on that remote device, but not locally

1
11527×897 66.7 KB

9

On device B, is there a valid (not ignored) file (not directory) that is a child of the directory you posted info about above? If yes, does a rescan change anything (the directory should become not ignored)? If nothing changes (I guess so), can you the enable scanner debug facility, together with db and model, and then manually start a scan on that folder.

10

The “Local Additions” seem to have fixed itself with time.

Device C:

1
1708×364 28.3 KB

Should I still do the scanning, or does it not matter anymore?

11

I have got those “Local Additions” today on Device C yet again, and I can confirm that rescanning the folder on Device B gets rid of them.

1 Like
12

I think what’s missing is that with the kind of include patterns you have ( !folder1/*/folder2), when we sync a file, we do not check if a parent is ignored (and if it is, un-ignore). However introducing that would be a lot of additional db lookups. Maybe a full iteration over the db after pulling to detect those, like when scanning, would be an option.

13

I can also add that I normally set my folders to rescan every 86400s, so it usually takes a while until the next scan happens, and this is probably why I happen to see the Local Additions on Device C quite often right now, and then they stay like that until the next scan on Device B, which can take up to 1 day.

Still, as long as the files get synced properly, this is not a big deal anyway. It is maybe a little annoying to have the folder stuck in sync between Devices B and C like that, but it is nothing too serious nevertheless.

1 Like
14

I’m not 100% sure, but it seems that the issue may not necessarily be caused by the exclude patterns…

I have now the same problem with a completely different folder that uses only very basic ignore patterns. There are also three devices involved though, but the folder is not shared between all of them simultaneously, which makes it similar to the situation discussed so far.

It looks like this.

  1. Device A shares a folder with Device B.

  2. Device A uses no ignore patterns.

  3. Device B uses the following ignore patterns.

    *.mkv
*.ts
*.mp4
*.pptx
*.mts

  4. The folder is marked as “Up to Date” both on Device A and B, and there no sync issues between the two.

  5. The folder has also been shared from Device B to Device C.

  6. Both Device B and Device C marks the folder as “Up to Date”, but there are files stuck in sync, i.e. Device B is trying to push files originating on Device A to Device C, even though they are ignored on Device B itself. The “Mod. Device” is listed as Device A.

    1
    11087×708 24.4 KB

This looks very similar to the original issue, i.e. there is a connection between A and B, and between B and C, but not between A and C. There are no funky ignore/exclude patterns involved this time though, yet the issue is still present.

Edit:

1 Like
15

I don’t want to speak too early, but I cherry-picked 273ee09 into my build yesterday, and since then both the stuck files and the local additions have disappeared.

The !folder1/*/folder2 ignore patterns issue is likely still here, as there are differences in the local states despite using the exact same patterns, but at least the GUI shows everything as “Up to Date”.

1 Like
16

I spoke a little too early about the local additions problem. The issue is still here, with the likely cause being the ignore patterns. As already tested previously, the local additions go away (temporarily) after scanning the folder on the other device.

The problem with files being stuck in sync is completely gone with the commit linked above though :slightly_smiling_face:.

17

Can you explain what exactly you are doing/experiencing now that is similar/the same as the original issue? The mechanism I understood previously is fixed now, so I need a new information setup :slight_smile:

18

I would say that there have been two issues described in this topic. The second came out later and was fixed in https://github.com/syncthing/syncthing/issues/7474. The original one, likely caused by the !folder1/*/folder2 ignore exclude patterns, is still present.

Basically, the issue described in the first few posts in the thread is the one that remains. I will try (again) to reproduce the thing in a clean environment to make it easier to trace and fix.

19

Ah yes right, the issue that you still do need to rescan for a parent of an un-ignored item to be recognised as not ignored.

20

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