Copied from this post on GitHub.
Proposal: Support absolute include paths in .stignore
I was setting up Syncthing again this week (old laptop died). I created
~/.stignoreglobal on my new Windows machine and went to work adding all my existing folders. I was quickly reminded that there is no way to
#ignore a file in each folder’s
.stignore using an absolute path. While not the end of the world it does make setting up the
.stignore in folders with various degrees of nesting a huge pain. I know y’all have said, in the past, that you would prefer not to reference files outside of the folder’s scope but I figured I’d throw out this proposal and see what y’all thought.
What it does
Allows users to include files in their folder’s
.stignore file using absolute paths.
Why people might want it
Makes it easier to manage your “global”
.stignore files. No more
../../../../ in your
How it works
A new keyword
#includeabs is available for use in your
.stignore. When Syncthing processes your folder’s
.stignore and encounters
#includeabs it treats the string after
#includeabs as an absolute file path for another
.stignore-formatted file to load.
What it might break
If implemented correctly this should not break anything.
Who will implement/test it
- I have an ignore file located at
- I have a Syncthing folder located at
- I have an ignore file at
I want Syncthing, when processing my folder at
~/Sync/Bar, to load the ignore patterns in
Without this proposed change
~/Sync/Bar/.stignore must contain the following line:
With this change an alternate version of that line could be:
which is, imo, much more readable.
I think we should go the opposite way and prevent including anything from external directories. We permit that file to be a symlink so people can use that. Supporting includes outside of the folder causes pain with filesystem abstraction.
Thanks for the response. I’m personally not a huge fan of symlinks; coming from a Windows background symlinks are still things I don’t naturally understand and I would not be surprised if others felt the same way. Additionally, on Windows there is pretty aweful support for symlinks, at least at this point.
For my own understanding can you go into a bit more detail on
Supporting includes outside of the folder causes pain with filesystem abstraction.
Why does it cause pain? How?
Every syncthing folder has a “filesystem” where the filesystem is rooted at the root of the folder. Meaning that accessing anything out of the folder should crash/fail and burn, this is to avoid various attacks such as breaking out of the folder by time based symlink traversal attacks and so on.
Supporting loading ignores from random parts of the filesystem suddenly makes this isolation code an unbearable mess that opens up potential attacks, which I’d rather kill than expand.
Also, I think this should live on the forum for starters as there is nothing actionable here for now, so no reason for this to be an issue on github.
Yeah there’s that thing, which is difficult to correct now for historical reasons. Regardless supporting absolutes in the stignore is indeed a step in the wrong direction so I’m going to veto it for that reason. Long term I still think we should get rid of ignore patterns in files as a concept and have some more elegant solution in the config/database with optionalish sync of patterns between peers.
so it seems that the core maintainers are against the
#ignoreabs which is fine. However I’d still like to find a better solution for managing “global” ignore patterns. What are people’s thoughts? Maybe we allow you to define different ignore patterns in Syncthing and “apply” them to folders? Ie, in the UI somewhere you click “Create New Ignore Group”, add patterns, and then check which folders to apply them to. What do people think?