Syncthing-android: Manual sync

[felixwiemuth]

As there are still problems with the service not reliably staying active in all setups (e.g. dying at some point and only coming back when visiting the app again or restarting the service), I suggest the following feature (which might even be a useful alternative for the service):

A "Sync now" widget (or simply a launcher shortcut) initiating a sync when clicked. In addition, if the sync service is enabled, it checks whether the service responds and, if not, restarts it.

This has the following positive side-effect: The user can decide not to use the sync service but let initiation of syncing be completely manual. The advantage is that one can save the resources needed for the sync service and that the user has a better control over when synchronization takes place. For example, one might not need steady syncing while working on one device, but when done changing files or switching to another device, one quickly hits the "sync" button, as one does with "save" for individual files. In comparison to periodic syncing, here one can be sure that the files are synced directly.

While the automatic syncing will stay a very useful feature, as long as it doesn't work reliably the above method will be much preferred and I guess it is quite easy to implement.

[nelsonblaha]

👍

[grwlf]

+1 added https://github.com/syncthing/syncthing/issues/4861 by mistake

[AudriusButkevicius]

This doesn't have much meaning, as syncing is a continious process. What if files never stop changing, what if a file changes just as we are about to disconnect etc.

It seems you are using the wrong tool for a one-off thing.

[grwlf]

OK) Lets say we want a button to manaully enable sync and disable it on, say, 5 minutes timeout without new incoming changes. A tool like that would save lots of clicks!

[felixwiemuth]

@AudriusButkevicius I don't really see you point. What does the service do right now? Apart from automatic detection of file changes (which can also be with the manual version) it also just starts scanning for changes at some point, only that the scan is initiated periodically instead of manually. So the problems you mention are general for syncthing and not specific to how/when a sync is initiated.

For manually initiated syncing, a guarantee like "all files changed until the initiation of the sync (scan) will be synced" would be enough.

It depends on the use case whether you find automatic periodic or manual syncing more useful. But at least as long as automatic syncing is not reliable, most users would prefer manual syncing as otherwise you cannot be sure whether syncing actually stopped.

[AudriusButkevicius]

Right, but you have to understand that syncing works both ways, it's not just send stuff, but also receiving stuff. You can't quantify once you received something as it's a continious process, as the other peer might he scanning.

Also, you might detect files, scan them, send info about them, yet the other peer might be in the middle of something else and not pull them, or even be offline...

Manual sync is essentially run rsync once, hence you should use something like rsync..

[grwlf]

Well, I do understand the sync basics. In theory, the best option would be to keep it always enabled. Unfotunately, given battery consumption, it is not the best case for anyone. Thus the suggestion - invent a mode of active syncing for a short period of time and then turn it off (reset to 'sync on wifi' or something).

[Catfriend1]

@grwlf This can currently be achieved by Tasker sending the syncthing start intent, wait x minutes and sending the stop intent. But with no guarantee your sync is 100% complete.

[felixwiemuth]

@grwlf Thanks for mentioning the possibilities with Tasker. The start intent is nearly all I was looking for initially.

However, if one also wants the service to stop again, I see the following option:

After manually initiating a sync at time ˋTˋ, for all clients that get connected within a certain amount of time ˋsˋ (thus until ˋT+sˋ), sync at least all changes happened before ˋTˋ on both sides.

• We call a sync with a client complete, if all changes happened before ˋTˋ on both sides are synced, where newer changes might have been synced as well
• If one of the initially connected clients disconnects before all those changes are synced, wait for a certain amount of time for it to come back
  
  
  
  • If it comes back, continue syncing
  
  
  • If it does not come back, stop the current sync for this client and send a notification (warning that sync was not complete for this client)
  
  
• When syncing with all initially connected clients is either complete or has been stopped because of timeout, syncthing can stop

Note that this way it does not matter which of two connected clients initiates a sync, the effect will always be that all changes happened before initiatiation on either side will be synced or the initiating client (optionally also the other) will be notified that the sync was not complete. Thus this approach takes the two-way nature of syncing into account.

[Catfriend1]

@AudriusButkevicius Any chance you would accept a PR on this. I understand its a mis-strategy encouraging the user to do manual, time-boxed syncs. Even so, I think the request for the enhancement is valid and would love to get that feature too. I often turn home, not needing immediate file sync all the time, also I do not need more complex run conditions, and when sitting at my desk I suddenly want to get my pictures off the phone (and sync to pc) so I launch syncthing and quit it about some minutes later.

To not make it too much complexity added in a PR, I would suggest going with "keep it as easy as Tasker". User gets a widget telling syncthing is running or not (another issue requested this as well). If the user clicks on the widget, a duration will be read from app preferences (set by the user before or default) and that time syncthing will stay on and then quit (countdown on the widget, pressing it again will increase the timer again the same duration). I even don't care about files not completely downloaded from the mobile because if something is missing (and important) I relaunch syncthing.

[AudriusButkevicius]

I think this is somewhat a poor solution, as nothing might happen in the N minutes syncthing was configured to run, then people will question if this works or not.

I'd like to see a more fleshed out proposal on the forum for discussion before you dive head first into this.

[Catfriend1]

Same as https://github.com/syncthing/syncthing-android/issues/769

Close

[Catfriend1]

Hi,

If you’d like to do the one time shot sync controlled by a third party app with syncthing that’s now possible by sending broadcast commands. See the wiki on how to do this: https://github.com/Catfriend1/syncthing-android/wiki/Remote-Control-by-Broadcast-Intents

Kind regards
Catfriend1

[vontrapp]

I'm interested in this as well, after a manner. I think the use case I'm looking for might be sufficient for the other asks as well.

First, the use case: I have a USB stick that is home to some syncthing folders, used to take the files to a computer not on the internet (or behind a firewal). Computer A performs the sync and computer B is behind the firewall. Computer B does stuff with files, changes some. USB is returned to computer A and syncing is performed.

Because I want to unplug this USB at some point to take it to computer B, I want to stop syncthing and unmount the USB. I want this to happen automatically so the USB light turns off, letting me know the sync has "completed".

Now the method: I think my case and the others can be accomplished by starting sync in a "stop when done" mode. I think the requirements are, and correct me if you think I'm wrong

• the "stop when done" node (the node) connects to at least one other node.
• the node fetches all files known about from the latest index obtained
• at least one other node is also fully synced with the latest index (has received files changed on the node)
  When these conditions are met, the node stops its sync process, preferably exits with a 0 status

Corner cases:

1. the node connects to node X, node X has an index from node Y but node Y is not available. X also does not have all files in the index (node Y has them). the node now receives the index but is unable to get all the files (node X also reflects an out-of-sync state)
2. the node connects to node X and obtains an index. Node X goes away before syncing completes, and the node knows it is out of sync but is not connected to anything
3. the node comes online, but no other nodes are available to connect to

In all these cases, time out eventually, giving up and returning with an error exit status.
Cases 1 and 2 would probably be the same (configurable) timeout value. Case 3 might be a different timeout value. Cases 1 and 2 perhaps a longer timeout value because it is known to be out of sync, so try harder (longer).

What do you all think?

[vontrapp]

Oh and I forgot to say, the node doesn't absolutely need to ensure all nodes are in sync, just that at least one other node is. After that, node X can continue to serve as a source for additional nodes to sync from.

Obviously a network of 2 nodes that are both operating in this mode would not make a lot of sense, but given an always on server node, it does make sense.