The new device limit for free dropbox accounts has been around for awhile, but I only just discovered it when I got a new laptop because apparently, existing devices get grandfathered in. So in order for me to install Dropbox on the new laptop, I'd have to remove dropbox from 13 other devices (which means I apparently have 15 devices with Dropbox installed). A few of those devices may be defunct, but I definitely have more than 3 that are actively using Dropbox.
Here was my thought progression on working around this issue:
- I started kicking around the idea of using rsync to keep a pseudo-dropbox folder on the new laptop up-to-date.
- Then I thought, it would be nice if those syncs happened in real time as things change (as opposed to running on a cron job).
- I discovered
fswatchthat could trigger rsync whenever anything changes in a computer with an active dropbox account.
- Then I realized, I'd want the sync to trigger from the new computer (without dropbox) as well if things change there and realized, I would have problems with 2 instances of rsync running from 2 different computers...
- I thought about adding a lock file in order to prevent different instances from running at the same time.
- Then it occurred to me that I only need 1 instance of rsync to run and just need to trigger it from 1 computer with dropbox installed and from each computer without dropbox... Thus: rPi & node red!
I know which computer I would use with a dropbox instance installed. It runs all the time. And right now, I only have 1 device that I want to add a pseudo-dropbox instance to, but there may be others in the future. And I'd like to do this in a way that will scale... I never installed the Dropbox container on the rPi, but I guess I could use this strategy to apply to the rPi as well.
I haven't used rsync a lot, but I assume that it can handle this. It's just a question of how to handle overlapping/multiple triggering events. Is there a node red workflow design scheme for keeping track of the change events in such a way that redundant requests don't trigger useless syncs but also not miss differences encountered on multiple devices simultaneously?
Like, let's take 3 devices: A, B, & C. A is the rPi, B is the only device with Dropbox installed and C is my new laptop.
Example: Change occurs on B. B notifies node red running on A. A starts the sync between A and B. At the same time, A notifies node red that something has changed on A's dropbox copy (but this is because of the rsync that's running - and thus should be ignored). The A/B sync finishes and then A moves on to sync A with C. C notifies node red that something has changed on C's dropbox copy (but this is because of the rsync that's running - and thus should be ignored).
Then, what if an actual change occurs on C while the A/C sync is running - and that change is missed... We ignored that notification because the sync was running...
- How do I implement ignoring redundant sync notifications?
- How do I not miss real changes?