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:)
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?
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?
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.
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.
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.
