Ignore pattern with special chars not working, v1.1.1-windows-amd64

[Catfriend1]

Hi,

I’m currently seeing this on PC 2 since v1.0.0 on Windows 10, amd64. Syncthing runs as a service under the SYSTEM account.

PC 1 says that PC 2 is up2date. PC 1 shares a whole Windows Drive (NTFS) to PC 2 (also a NTFS drive root). PC 1 is sendonly, PC 2 is receiveonly. Both use large blocks (I think that doesn’t matter…). Both use local hard drives. They see each other permanently on the same local network with static IP addresses.

“#nosync” and “$RECYCLE.BIN” on the drive root are ignored by .stignore on both the sending and the receiving side.

Hitting the “Revert” button on PC 2 doesn’t (visually) do anything and the problem persists. Since I have this problem a little longer, I recall it came when updating from 0.14.54 to 1.0.0. I then waited and later updated to 1.1.1, this didn’t change anything.

My Syncthing ignore patterns for the affected folder (in this case whole drive) are those - on both sides:

(?i)/#recycle
(?i)/#nosync
(?i)/$Recycle.bin
(?i)/$RECYCLE.BIN
(?i)/System Volume Information

.stignore is located in the drive root as that is the path where the Syncthing folder points to. (C:)

Any ideas what I can do to solve this?

Thanks for your help.

Kind regards Catfriend1

[Catfriend1]

Just playing around to see if I can solve this… but no luck until now.

What I did from Admin “cmd” on both sides:

• rd /s /q C:$RECYCLE.BIN
• Hit “rescan all” button on both sides
• The revert button still appears on PC 2 (39 files changed report, files below #nosync and $recycle.bin)
• Set ENV VAR “STRECHECKDBEVERY=0” (as in the other topic)
• Restarted syncthing instances.
• The revert button still appears on PC 2 (39 files changed report, files below #nosync and $recycle.bin)
• Unset ENV VAR.

[calmh (Jakob Borg)]

Ignore patterns seem to be matching as expected for me at least. Perhaps some interaction between ignored files (deleted or not?) and a recv only (?) folder?

[Catfriend1]

Ok after observing a while, the recycle.bin folder’s differences were no longer reported on the PC2 (recvonly) side after I deleted that folder manually. Instead, Syncthing on PC2 shows new files that “should need revert” from System Volume Information. I cannot delete this system folder as it would brick my drive logically. I’m absolutely in the dark and have no clue why Syncthing picks up files from ignored folders in recvonly mode. So your hint isn’t far away from what I see. Some weeks ago, I had the same on a linux(sendonly)<>Linux (recvonly) folder pair at my workplace. I’ll later post screenshots how it looks now. The global state on PC2 is X files greater than the one on PC1. I tried changing the ignore patterns, e G. To System* and the rescan didn’t change file counts. Would it also help if I upload my database from PC2? My feeling is somehow those folders like System Volume Information were picked up and never forgotten…?

[imsodin (Simon)]

Can you post the output of the file endpoint (https://docs.syncthing.net/rest/db-file-get.html) for one of the files, ideally from both sides.

[Catfriend1]

@imsodin

PC1:
{
  "availability": null,
  "global": {
    "deleted": false,
    "ignored": false,
    "invalid": true,
    "localFlags": 0,
    "modified": "2016-07-27T21:36:29.8157165+02:00",
    "modifiedBy": "PHZHAMF",
    "mustRescan": false,
    "name": "System Volume Information\\Chkdsk\\Chkdsk20160727193629.log",
    "noPermissions": false,
    "numBlocks": 1,
    "permissions": "0644",
    "sequence": 62888,
    "size": 5120,
    "type": 0,
    "version": []
  },
  "local": {
    "deleted": false,
    "ignored": false,
    "invalid": false,
    "localFlags": 0,
    "modified": "1970-01-01T01:00:00+01:00",
    "modifiedBy": "",
    "mustRescan": false,
    "name": "",
    "noPermissions": false,
    "numBlocks": 0,
    "permissions": "0",
    "sequence": 0,
    "size": 0,
    "type": 0,
    "version": []
  }
}

PC 2:
{
  "availability": null,
  "global": {
    "deleted": false,
    "ignored": false,
    "invalid": true,
    "localFlags": 8,
    "modified": "2016-07-27T21:36:29.8157165+02:00",
    "modifiedBy": "PHZHAMF",
    "mustRescan": false,
    "name": "System Volume Information\\Chkdsk\\Chkdsk20160727193629.log",
    "noPermissions": false,
    "numBlocks": 1,
    "permissions": "0644",
    "sequence": 62888,
    "size": 5120,
    "type": 0,
    "version": [
      "PHZHAMF:1"
    ]
  },
  "local": {
    "deleted": false,
    "ignored": false,
    "invalid": true,
    "localFlags": 8,
    "modified": "2016-07-27T21:36:29.8157165+02:00",
    "modifiedBy": "PHZHAMF",
    "mustRescan": false,
    "name": "System Volume Information\\Chkdsk\\Chkdsk20160727193629.log",
    "noPermissions": false,
    "numBlocks": 1,
    "permissions": "0644",
    "sequence": 62888,
    "size": 5120,
    "type": 0,
    "version": [
      "PHZHAMF:1"
    ]
  }
}

PC2:

I took the System Volume Information\xxx file as the same thing happens with it as I described above for the $recycle.bin files (both folders are ignored by patterns in place on both devices). I’ve deleted $recycle.bin yesterday on both PCs.

[AudriusButkevicius]

This looks like a bug in recvonly when comparing local and global when both are invalid. I assume the text translated to english says something like local changes on pc 2, and the dialog is from pc 2, and visible on pc 2 only?

Also, it seems pc 2 was sendrecv at some point when this file was advertised, as I think PHZHAMF is pc2?

[Catfriend1]

@AudriusButkevicius Yes, your assumptions are totally correct :-). The folder was sendrecv before the release of the recvonly feature and was then turned recvonly. PC2 = PHZHAMF and it shows this “Revert local changes” dialog only. PC1 does not indicate that there are any out-of-sync objects, it says “Up2date”. Should I nuke the database and rescan or is there hope that it’ll get fixed in a future release?

[calmh (Jakob Borg)]

It’s never completely hopeless.

[AudriusButkevicius]

I think this is worth a bug report first, but yeah, blowing everything away will fix this.

[Catfriend1]

Link: https://github.com/syncthing/syncthing/issues/5677

[imsodin (Simon)]

I don’t understand what’s hinting at the transition from send-receive to receive-only being the culprit? What’s incorrect is, that localFlags is 8/locally changed, while it should be ignored. Items are marked as ignored on every scan regardless of folder type, so something seems to be wrong with ignoring to me. Though no idea what and how to debug.

[calmh (Jakob Borg)]

Maybe the ignore patterns were added after the locally-changed files were discovered? PC1 sees no instance of the file except the invalid one announced by PC2. PC2 sees only their own locally-changed tagged file which is now also covered by an ignore pattern.

So I could see a potential bug to look closer for in handling of previously not ignored files that are now ignored on a recv-only folder… Probably they’re already being skipped here and there because they are invalid, but maybe not by the revert check? But the actual revert might still skip them because they are ignored, so no revert happens.

[Catfriend1]

Sorry I can’t follow the technical parts as I lack some deep code understanding. I’ll currently let the problem persist as it is, so we can continue debugging at any time. Just let me know if I can help here. If we find a better more precise title for the issue, please tell me, too :-).

@calmh: The ignore patterns are in place like this for quite a long time, they should be there even before the change from sendrecv to recvonly on PC 2 occured.

[imsodin (Simon)]

The thing is at the end of the scan we traverse everything we have in the database, including invalid files (whether ignored or otherwise), and check for deleted and ignored files. And if a file is not ignored, it is marked as ignored. It shouldn’t matter whether the file was discovered when send-receive or receive-only.