Not sure where to put that, feature or support, but I definitely need some help at least to understand how this works, because it doesn’t meet my expectations. So I’ve set up new folder on local (send-only) and remote (receive-only), did a full sync. Then I added ignore patterns on local, so that reduced folder local state count. But global state count remained the same so the change is not propagated to remote. Is it correct behaviour?
The fact you ignored something locally doesn’t mean remote devices should now delete these files, so the files are still there and available globally, just not from the device that has them ignored.
So if .stignore can’t be copied what are the other ways to have exactly the same copy on remote?
You can copy it manually, or you can set it up to include another file that is synced.
That will still not affect the global state I believe, just an FYI.
So what’s the purpose of ignore list? Just to perform initial sync? It’d be more useful if it’s dynamic nature used to represent current state
The purpose is to ignore files from being synced, in either direction. But it’s a local decision, you ignoring a file doesn’t mean everyone else has to.
Effectively, once it’s announced and made into the global list, and ignoring has no effect as it acts on the local level.
Global is just a merged state of all local states.
Ignoring however prevents things from being added to the local state, which transitively means prevents stuff being added to the global list.
I think it should disappear from global state as well once everyone ignores it, though.
1 Like
Yes, the global state count is reduced when I #included custom ignore file on remote. That’s a pity there’s no way to enforce/distribute ignore policy in more elegant automatic way
2 Likes
I am not sure that this is working correctly though. I have seen this numerous times, and even right now, where I have a folder shared between two devices. It is set to “Receive Only” on Device A, and to “Send Only” on Device B. Adding new files to .stignore on both sides does not change the previous global state, even though there are no other devices sharing it.
To fix this, I need to either remove and re-add the ignore patterns to the folder, or wipe out the database and let Syncthing re-index everything from scratch.
Might this be particular to the receive only thing? That one is a bit special.
What does that mean exactly? Internally there’s nothing special about removing patterns, it’s just a pattern change the same as adding a line with a new pattern.
It may be so. This happens on the “Send Only” side too, which theoretically should not be possible 
. I have also experienced a lot of issues when switching the folder type later (e.g. from “Receive Only” to “Send & Receive”), such as the folder’s local and global state being different, even after completely unsharing the folder from other devices. This may be a different issue than the .stignore one though. The problem is that I have not been able to reproduce this with a clean pair of folders, as this always seems to happen only with some of the existing folders, with a lot of files involved, and a lot of activity taking place basically all the time.
What I meant is to remove everything from .stignore, let Syncthing rescan the folder with no ignore patterns, and then add the patterns again. Doing so makes the global and local states match again (at least for the “Send Only” folder).
Thanks! I could repro that when you ignore a local change on a receive-only folder, it gets removed from the local, but not global state (no remotes involved). Not sure why and whether it’s the same thing you see, but definitely a bug - looking into it.
And the problem is spotted. Should have realized it earlier, given the metadata mismatches always came up together with with non-send-receive folder types. Both ignored and locally changed items are “invalid”, thus when updating globals we consider them unchanged and take a shortcut. However metadata does care about why they are invalid (flags), not just that they are invalid. I created an issue on github (https://github.com/syncthing/syncthing/issues/6850) and will work on a fix.
4 Likes
It definitely does sound like the issue that I have had. In my case, this wrong global state would also display on the “Send Only” side. I will try to cherry pick and test the commit sometime later.
1 Like
I think this might be a “me too” regarding my other ticket with my SO/RO setup. Thanks for fixing it.
1 Like
Please let me know when/how a problem occurs on the send-only side. In a super-simple setup (as in local only) I can’t produce any problems. And the current fix shouldn’t really have any effect on send-only folders, so it might be something else.
I would need to try to reproduce this on a clean pair of folders… but I think this may be the case after you change a “Receive Only” folder with a broken global state to a different type later, e.g. “Send & Receive”. The incorrect global state seems to propagate to other devices then.