Both of those are kind of reasonable. I had a branch or just issue or something filed to move ignores into the marker directory, since that’s what it’s for. There are migration difficulties, like how do we interpret existing #includes and such. Maybe we should try multiple locations in order ($marker/ignores.txt and then .stignore if that doesn’t exist, or some such).
2 Likes
Yes, with my very limited skills I only managed to move .stignore into a hard-coded .stfolder, without using the $marker or worrying about backwards compatibility, but it did not really help with anything (except for reducing the visual clutter a tiny bit), so I eventually gave up.
I’m somehow dreaming of having .stignore at /folderroot/.stfolder/.stignore . Because: we already can configure the folder markers name and I could then share the same root folder two times as two different folder id’s. That would give me the opportunity to rename the folder markers of both like .stfolder1 .stfolder2, each having a .stignore in it. In this case I could get rid of the junctioned directories on Windows by sharing the same folder two times with different local ignores.
2 Likes
Issue is up for grabs.
2 Likes
Hi Synchers I have 2 questions about shared patterns (#include or other way).
Let’s say I use #include $FOLDER/some-path/someFile (utf8, I read the doc).
As long as the option Auto Normalize is left set to its default yes can we seamlessly use any of the directory separators / or \ in patterns in a mixed Win/Nux cluster ?
The other question raises about when editing the said someFile: when is the change taken into account by devices that rely on the file? Special scan? Wait for normal FS watch? Wait for full rescan? Checked on Folder/Device/Machine resume ?
I ask because I have a 60GB folder with ~150k files that hogs mechanical consumer grade disks and for them I had to change Rescan Interval to 12h (and disable restart on Wakeup for laptops that go to sleep).
Thank you
Auto normalization has nothing to do with file separators, that’s about encoding. For ignore syntax a path separator is always a slash ( Wrong, see later posts./).
Whenever there’s any scan or sync/pull, the ignore patterns are checked for changes. And a change to an included, synced file is like any other change, i.e. it will get picked up by watching and periodic scans.
Thank you Simon
Glad for the second answer 
So there is something puzzling me: when I first tested the #include keyword in the GUI (Windows) I used \ for the separator and I made a mistake in the path to the file (forgot a dir level), which ended in error (approx “could not load file”). So I went to .stignore to check, found my error and everything went OK but some files that would be ignored were synced in the lap time, maybe I forgot a pattern. But I had both the path to file and the patterns with \ and it worked (in fact there is no Linux in this cluster, it’s for a friend personal use, pure Windows until now). I asked the question for my own mix use. After your answer changed both path and patterns to / and it seems* to work too. So is there a mechanism that transforms any / or \ we use to fit to the OS?
*not so sure: a single pattern with the \ and I can’t remember if I created the related dir everywhere before.
For the path given to #include both slashes and backslashes are indeed ok. For patterns it must be slashes though. There’s no special mechanism, it’s just that the go package used to handle the path given to include can manage both. Wrong, see later posts.
1 Like
Thanks a lot, this is the ultimate answer I hoped.
This is worth a Note in the doc!
Agreed, but for simplicity’s sake I’d just state “slashes ( Wrong, see later posts./) only as directory separators” in ignore patterns. Adding any distinction between include and the rest is just unnecessary complexity that is a source for confusion.
And as usual, please consider contributing any improvements you’d like to see directly to https://github.com/syncthing/docs 
I’m pretty sure backslashes as separator in ignore patterns is fine on Windows?
2 Likes
They are. I personally use / just for consistency between different operating systems, but \ does work on Windows too.
Right, one of the first things done to the input is normalize the separators, so both types work. Thanks for correcting (edited above).
1 Like
I changed my mind, and several weeks ago added the commit to my personal Syncthing build. Since then, I have been syncing .stignore like any other file.
It actually works great. There is no need to manage ignores on each devices separately any more, and if I do need to do so, I can just add .stignore to the ignore list on that machine, which will then make that ignore list local (i.e. mimic the default Syncthing behaviour).
2 Likes
After reading this thread and this comment, I’ve been thinking if a built-in global and local .stignore system would be a good idea, mimicking your setup. My idea is that every folder has a tab for “global ignores” and “local ignores” in the folder settings (under the already existing “Ignore Patterns” tab).
The global ignore rules would be applied to all devices within in the cluster, and would obviously have to be the first file pulled before all others.
The local ignore rules would be used to add rules that aren’t needed on other devices, or to be used to overwrite a rule in the global ignores list.
I’m initially thinking this would make managing ignores a bit easier, however I’m not sure if there’s enough use-case scenarios for it to be worth it, and also it might be too complicated.
1 Like
Yes, that sounds very cool. It would definitely allow for more personalised configuration. My solution is really just a quick, brute-force workaround 
.
Awesome, then we’re at least two who would use it! The question still stands if there’s a wide enough use-case for it. However, I haven’t really developed in Go, so I wouldn’t know where/how to start 
You can already achieve that by using include directive.
That’s true, however the current implementation does not allow including a file when the folder is added to a device. Adding for example #include .globalstignore to the rules when initially adding a folder will just throw an error, as the file doesn’t exist locally yet, which makes sense.
However I think it would be much better if Syncthing instead would pull the file(s) specified in the include(s) (if they exist in the cluster), apply those rules, and then begin pulling all other files.
The error thrown is this one
2020-08-02 19:13:19 Error on folder "Test" (94clu-ucu8j): loading ignores: failed to load include file .globalstignore: open \\?\[folder path]\.globalstignore: Det går inte att hitta filen.
1 Like
One solution could be a flag for optional includes (missing is not an error) combined with default ignore patterns (we want those anyhow).
Chicken-and-egg problem remains, but that’s the case with any synced-ignores setup…