When using a tool like CopyQ I’m finding that the synchronization doesn’t occur until the “receiving” computer has had CopyQ activated from the menubar to show the actual main window. I suspect that this somehow prompts a filesystem read and then causes Syncthing to try to pull the updates in.
Is there any way to trigger updates from the “sending” system vs the recipient for some folders? It would be nice to trigger a force to cause updates / sends / syncs to occur more quickly vs having this check-egg scenario since it completely obliterates the goal of sharing clipboard contents rapidly and is an entirely undesirable effect.
'ppreciate the input there @chaos. Are you saying that by triggering this scan on the local sending machine that it will force all recipient machines to receive the updates right away?
That’s very nearly what I was trying to say. As I understand it, when Syncthing sees a change (from the filesystem watcher or from a scan) it works through the syncing process. In other words, yes, given possible delays in that process.
Each device sends changes they detect as they detect them (via scanning or filesystem notifications). Each device that receives the changes pulls them as soon as the folder becomes idle (is not scanning or already syncing)
So the device that has changes shouts out “I have changes” and the other devices take notice and grab said changes as soon as they are able.
Therefore using POST /rest/db/scan from an app that makes changes to a share that needs to be propagated essentially triggers the shout out to the other devices so then they’ll pull, right?
The synchronization process is explained at Understanding Synchronization — Syncthing documentation but basically yes — triggering a scan leads to the “global version” of the file being updated, which in turn leads to other devices requesting any missing blocks.