I read some threads about ‘selective sync’, asking for either file-level or subdir-level selection:
It seems to be a common request from Dropbox and Bittorrent Sync users. Nevertheless, I understand the arguments given by @AudriusButkevicius about the inherent scaling limitation. Such granularity would be overkill for my needs, anyway.
However, I’ve come across a use case where selectively (de)activating the syncronization of entire repositories can be helpful, and I hope it doesn’t involve a computation overhead. The minimal case would be:
A user is using syncthing to connect two devices (A and B). Two repositories are shared: ‘doc’ and ‘tests’. Since only pdf files are to be saved to ‘doc’, it is not expected to have much activity. Then, it can always be active. On the contrary, A and B are expected to run various simulations and save the results to ‘test’. When A is running long simulations and producing few files, and B is running multiple relatively short ones which create lots of files, it’d be helpful to temporaly avoid B from publishing the changes to remotes.
I read the documentation and tried both Syncthing and SyncTraizor, but I found no obvious solution. I also tried to manually edit the config file, but it requires restarting Syncthing for the changes to take effect.
I suppose it may be made by just not updating the global state from B/test or deactivating the scan interval, if the box is unchecked. At the same time, it should be decided whether to get the results from A/test or to keep B/test completely disconnected until the box is checked. Can this be handled from the GUI? Or is it a feature of the core to periodically check all the repositories in the config file?
Last, I know the following workarounds:
- Not to run such simulations in a repository. However, most of them do not produce many files, and I’m trying to avoid reconfiguring the tools.
- To remove/add the repository. At least three clicks are required to remove it, and the path has to be specified for it to be added later.
- Running two instances of Syncthing, which would require managing two different configurations.