cjnaz
commented
3 years ago This is awesome. There was a prior request for inotify support within rclonesync so as not to have to put it in a cron job. Since to make this work the cloud service would also have to provide inotify support. It looks like you've figured this out for Dropbox. I wonder about other cloud services, or perhaps a generic solution? I propose that you create a repo in your github home and I'll post a link to it as an application. If you prefer, I'll add this to my repo but I'm not in a good position to support it.
bshensky
No issue, just want to contribute...
Rclonesync is the keystone of my local setup to allow for 2-way sync of a local volume with a Dropbox cloud account. The volume/cloud manages ~80k files at about 400Gb in size.
"Inotifywait" looks for local changes to the volume and, when seen, uses "at" to queue an rclonesync job 5-10 minutes into the future. This is done to allow any immediate file management work to cool down.
On the Dropbox side, a Webhook is established to ping a local Web server (with appropriate firewall rules, of course) when files change in the cloud. On change and Webhook "ping", the same rclonesync job as above is queued.
Rclonesync jobs can only happen "on the fives". This guarantees that multiple concurrent sync requests (from either inotifywait or the Webbook) can be disregarded after the first. It prevents unnecessary multiple spawns of rclonesync during the cooldown period.
Finally, while not absolutely necessary, I'm using the rclone "cache" plugin to overlay my Dropbox config. This dramatically increases rclonesync's performance on upload-to-cloud operations, but at the expense of Cloud volume concurrency (I have a 1 hour cache expiry on the "cache" plugin config). Dropbox Webhook initiated requests include a flag to ignore/purge/rebuild the cache as part of the download-from-cloud operations.
My control scripts are attached for your review.
Thank you for such a wonderful tool!
vault_rclonesync.zip