Instead, I would like to sync my project folder. But sometimes I work with disk images of embedded systems, and I have a habit of just mounting them right there alongside the images. For example, mkdir tmp; sudo mount -o loop filesystem.bin tmp. Similarly, I sometimes mount sshfs of a remote system.
With rsync, I could use --one-file-system to exclude any mounted directories. Is the same possible somehow with syncthing?
In the meanwhile, just using an exclude pattern and trying to remember to name the mountpoints accordingly works ok.
Would you welcome a patch adding some kind of ignore prefix like (?m) that would match only mountpoints? That could then be used e.g. (?m)*, or with more specific naming to only exclude some mounts.
I don’t think (?m)* makes much sense, ignoring crossing filesystems is definately not a task for ignore patterns.
It could be added as an option to the fs package, not to traverse down into other filesystems.
Perhaps we could add a new filesystem type called local which is effectively the same as the current poorly named basic but which changes the path it gets given on construction from being a path c:\foo\bar or /foo/bar to being a URI ala file:///c:/foo/bar?option1=foo&option2=bar, and then all of these feature flags could be in the query string.
Alternative could be yet another folder configuration options, which yet again gets pushed down into the scanner, which yet again does work that the filesystem package could handle.
I don’t think I understand the URI proposal properly. That’s not meant to be user facing, right? And if we imagine having more such options, having a new filesystem type per option (and then combination of options) doesn’t seem handy either. Then we’d still need some sort of config element for the user/api part.
The idea behind filesystems is that they should be identified by URIs rather than paths. The URIs can be translated to paths, so you can translate file:///c:/foo/bar?enableFeatureX=true&enableFeature=y to c:\foo\bar and at the same time have a place where additional configuration options can land.
Same way like we have for discoverys server URIs, relay uris, and even listen address URIs.
Alternatively, we just add a free form map[string]string of options that the user can specify in the config that gets passed to the file system during initialization. I guess this is less crypting and less extraction going on.
Discussing how exactly to store/pass around options feels way too early at this point. In my opinion the relevant point made was that the functionality should live in filesystem. If @PetteriAimonen or anyone else picks this issue up, it makes sense to discuss about such options, right now it feels like wasted time.
Another high level requirement I’d have for such a feature to get merge is that it applies to “all common cases”, e.g. bind mounts on linux, reparse points on windows. I don’t want to have a clearly incomplete feature which can trip over users (there is obviously always a big solution that there’s some niche functionality that’s not covered, that’s fine).