Sync activation checkbox (repository-level)

Hello,

I read some threads about ‘selective sync’, asking for either file-level or subdir-level selection:

[Sync All / Sync on demand]

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.

Isn’t that still wip?

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.

Temp indexes != Persistent indexes.

The number of indexes in this project is too damn high!

You meant delta index

(How do you do these fancy github previews?)

What actually happened to that one?

You do that by putting the URL on a line by itself, without indentation :slight_smile:

Thank you for replying so fast.

Do you remember if there is any public info about what you agreed on? May it be this?

[quote=“calmh, post:9, issue:215”]As I see the “pause sync” feature (that this issue is for), it would;

  1. Be per repo, i.e. not global (although you could pause all repos one by one)

  2. Prevent scanning, i.e. when paused we do not scan for local changes

  3. Prevent pulling, i.e. when paused we do not try to get outdated files in sync

  4. Not affect connections, i.e. we still connect and attempt to stay connected to other nodes (this includes sending periodic ping messages).

  5. Not affect incoming data, i.e. we don’t try to stop other nodes from sending us index updates[/quote]

Anyway, in your responses to this thread I’ve realized that you are already working on a solution which may solve this use case:

[quote=“Tracerneo, pull/2417”]Particular master/slave setting combinations should work as described:

  • both false – normal push&pull folder, keep in sync

  • master true – push-only folder, not accepting changesets

  • slave true – pull-only folder, copy pushing nodes, always override local changes

  • both true – no push nor pull, locally inform about sync status, possibly allow downloading as a mirror[/quote]

When that feature is merged to the main branch, either slave true or both true will suffice.

Meanwhile, is it secure to point syncthing to a symbolic link and remove it to emulate the “pause sync” state?

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.

1 Like