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.
There is a pause button by device in v0.12. We never agreed on what the pause button for folders should mean (or I couldn’t easily implement what we agreed on, I don’t remember) when I tried to implement it, so it got left out.
I had a pretty good working solution for pausing a folder on my Android where a Tasker like app would react to Wifi (dis)connect and would rename the .stfolder file and change the .stignore so it would ignore everything.
Every change (new file, file deletion, file modification) on both sides were synced correctly after “restoring” the files.
It worked ok in my tests, but one night for some reason the switch did not work correctly so I blew through my data cap as the phone transfered almost 2GiB via mobile data. I think it was caused by a combination of app standby, wifi standby and doze.
My implementation stopped the folder locally, which is pause in the sense that the local device does nothing with the folder. Problem is, it doesn’t prevent other devices from sending index updates about it, or requesting blocks for it.
To do that properly you’d pretty much need to drop the connection to every device sharing the folder on pause, then reconnect and not advertise the presence of the paused folder.
That reconnect may be expensive by itself. Resuming a folder would require the same. Or a protocol change.
Pausing a device is more straightforward - we disconnect, and prevent new connections to that device from happening.
As soon as temp delta indexes are implemented, a reconnect shouldn’t be that expensive in regards to data transfer, right?
I forgot about the index updates in my “solution”. I could live with a little data to be transfered and there would be no pulling, as this folder is only shared between my server and my phone, while new data is only generated on my server.
If the symlink is the main folder, which is set up in syncthing, it should be more or less the same situation as my “solution” above. Syncthing will not scan or send updates, but will receive index updates from other nodes which causes traffic.