My solution for something like this are bind mounts, but that doesn’t exist in Windows.
Using symlinks also doesn’t work, as Syncthing currently does not follow them, see:
syncthing:master ← calmh:symlinks
opened 08:23PM - 20 Jun 15 UTC
This adds symlink following. It seems to work, but there's a pretty serious cave… at about reconfiguring FollowSymlinks true -> false that basically deletes all your files unless you're careful... (I'll write some docs) I'm thinking about getting this in there without a UI option, as a hidden test feature for a release or two before letting it be widely known...
I’m offering a bounty of 600 US dollars for a per-folder setting for how to handle symlinks in the Linux client. A select box with the following choices, per folder, would be sufficient to fulfil my needs, though I’m open to discussion of other ideas:
A. Ignore symlinks found on the source filesystem, which is how Syncthing currently behaves.
B. Follow symlinks found on the source filesystem. Loop detection is done to prevent infinite recursion, and links that would cause loops are not followe…
The only working (but ugly) solution I can think of for Windows would be to share each sub folder as its own Syncthing folder to CLIENTS-B or split the huge folder into 2 and share both with CLIENTS-A and only one with CLIENTS-B.
In the future, the ignores will probably be stored in the config not inside a file, so your initial idea would work.
opened 01:59PM - 19 Nov 15 UTC
documentation
This issue replaces the ones that relate to fundamental issues with how our igno… res work. The following is the up to date list of requirements:
### Certain Requirements
- Must be understandable by someone who understands the interface in use by DropBox, OneDrive, etc.
- Must be a simple tree view with checkboxes
- Root of tree (=folder root) checked by default
- Can uncheck root and then check just the branches that we want synced
- Must be able to black list extensions
- Must live in config (not .stignore files)
- Must "live update". That is, if I ignore a file that was going to be pulled, we should not pull it. If I unignore a file that we are missing, it should be pulled shortly thereafter.
- Must be able to specify if ignored files should be preserved or removed on directory delete.
- Per what though? File extension? Directory?
- Power user access to flexible, underlying patterns
- Be able to to remove files for folders that are not picked, as it remove things that are now ignored.
- Have inclusion and exclusion mode, ignore everything, include X, versus include everything, ignore X.
### Maybe?
- Per directory file extension black lists ("never sync `*.tmp`")
- Per directory file extension white lists ("only sync `*.doc`")
- Should sync between devices
- Ability to ignore a directory by the presence of a special file in it (`cachedir.tag`).
Comments and discussion below. A project maintainer will keep the list above in sync as the requirements change or are clarified. Note that this is not a list of problems with the current system, but requirements for a _new_ system.
1 Like