Is there a way to apply ignore patterns and see the files that will be synced before accepting a sync request on another Syncthing device?
Unless I am overlooking it, neither the web UI nor the CLI seem to have this functionality.
No, it’s a catch-22 because a ignore patterns file doesn’t normally exist until after a sharing request has been accepted (unless a .stignore file was manually created outside of Syncthing).
Perhaps find-stignore (https://github.com/paulhargreaves/find-stignore) might be useful for your use case.
1 Like
I do not think that is the case anymore. Recent versions of Syncthing offer this option when sharing a folder:
[checkbox] Add ignore patterns
Ignore patterns can only be added after the folder is created. If checked, an input field to enter ignore patterns will be presented after saving.
After following that procedure, the folder I seek to share, the reason for this post, does indeed have a .stignore file containing the expected configuration in it. It is currently being shared to only 1 peer, with the request pending on that device.
Thanks for sharing that tool. It seems to do the trick but I have to disable https on my device in order to get it to work. Otherwise I see this:
2023/04/01 16:42:19 Get “https://localhost:8384/rest/system/config”: tls: failed to verify certificate: x509: certificate signed by unknown authority
hmmm… perhaps I misunderstood… I thought you wanted to be able to see the list of files that would be synced on another device after factoring in ignore patterns.
Checking the “Add ignore patterns” box will display the input field after saving, but the ignore patterns apply to the device its on.
Or in other words, given devices A and B, you create a new Syncthing folder on A, then share it with B. The ignore patterns that were added while creating the folder on A apply to files and directories being downloaded to A, not to B (the ignore patterns don’t filter what is sent to other devices).
Yes, that type of error above is unfortunately unavoidable when using a self-signed certificate. If your connections to Syncthing’s GUI are only via localhost (aka., 127.0.0.1), then disabling HTTPS is an option because the network traffic never leaves the device (find-stignore needs access to the local filesystem so it doesn’t normally work with remote devices anyways).
That’s wrong I think. Ignore patterns apply to local files as well as the list of files received from remote devices. (Except for telling other remotes about the existence of items in the “global state”, i.e. as received from third parties.)
To get a preview of what will slip through your ignore patterns, you could set up another folder share under the same path, with folder type receive-only, not shared with any other device. Then you will have “local additions” which will only list any files not matched by your ignore patterns. When you’re satisfied, just copy the patterns and apply them while accepting the real folder invitation from the remote device.
The same thing works in the other direction to see what would be received from a remote device without actually downloading it. Accept the folder as type send-only, pointing to an empty path on your device. It should then show a list of “out of sync items”, which takes into account the remote device’s ignore patterns as well as the ones you set locally.
That is what I wanted, yes (before the sync invitation was accepted). And I was able to get it by using the tool you recommended.
@acolomb, I think you are correct, and it only makes sense. Why would I not want to ignore incoming files that might clobber existing ones? Given the fact that there is only one ignore list with no distinction between incoming and outgoing files, how else would I prevent such things? Trust device B to be nice? I think not!
Yes, I see the same error when putting https://localhost:8384 in my browser but the interface still loads.
As insecure as it may be (and even on localhost it’s insecure; for one thing, modern OSes are typically multi-user), all it would take is for the tool to provide the option to not validate the CA. And I may end up modifying the Go script myself to do just that, but even better would be to build this functionality right into Syncthing itself. 
Thanks for the assistance! I’m glad I was able to get the tool to work, regardless.
Thanks @acolomb (and @hexadecagram). You’re both right. I’d been under the impression that the ignore patterns applied only to the device they were on rather than having an almost global effect across devices.
Well it’s not a global effect either. If device A ignores files named FOO (which may not or may not even exist locally), but another device B has a file of the same name, B will add its presence to the cumulated “global state”, while device A will show it’s out of sync because of that locally ignored file.
It’s a bit subtle. Ignore patterns are indeed only processed locally (when scanning files on disk, or when deciding whether or not to sync a change from the outside). If a file which matches ignore patterns is discovered locally it won’t be scanned, won’t be recorded in the database, and nobody else will be told about it. However if such a file is announced by another device (which presumably does not have an ignore pattern for it), it is taken into the database but flagged as ignored. It will be announced to other devices with an invalid bit set, so other devices can deduce that the file might exist, but they can also see that this device doesn’t have it. The same happens when a file becomes ignored that previously wasn’t, because we can’t make other devices simply forget that we announced it – we must send an update with the invalid bit set. That affects the externally visible state, so it could be said to be some sort of global effect.
Global in the sense that other devices now know that this device considers the file invalid, but not global as in every other device starts marking it invalid / ignoring as well. Right?
Of course.