This is going to be a series of two blog posts wherein I would be discussing an approach alternative to Dropbox's Blacklisting Based Selective Sync.
Yes, I am talking about Whitelisting Based Selective Sync in Dropbox. This approach for selective sync though is not natively supported by Dropbox but may come handy in certain use cases.
In the first part of this series, I will be first explaining both the black and whitelisting based approaches for selective sync along with the use cases where they fit the most, following which I will be introducing the script that I wrote to achieve whitelisting based selective sync besides explaining what and what not to expect from it. You can get a glimpse of the script here, if you like so!
In the second part, I will be explaining how could you either integrate whitelisting based selective sync with the dropbox instance already setup on your machine or setup both dropbox and whitelisting selective sync togehter as a docker container. The later approach being the preferred one.
Understanding Selective Sync
Dropbox supports Blacklisting Based Selective Sync, natively. What it means is that you as a user can explicitly tell Dropbox which files and folders you aren't interested in syncing on your local machine.
As depicted in the diagram above, all the files and folders blacklisted are desynchronized and removed from the local setup. These files and folders however would still be available on your Dropbox account, accessible via web interface or other Dropbox instances.
On the contrary, in a Whitelisting Based Selective Sync scheme, only files and folders whitelisted will be synchronized, rest will be desynchronized and removed from the local setup, as depicted below.
Since the Whitelisting Based Selective Sync is not natively supported by Dropbox, the only way to go about implementing such a scheme is via blacklisting itself. You can have a look at the script I wrote just to achieve this; not shown here for the sake of brevity. In particular, this scheme allows user to maintain a whitelist and at a regular time interval, the files and folders that don't match the files and folders listed in a whitelist are blacklisted thereby achieving whitelisting.
While considering whitelisting scheme explained above, an important thing here though to understand is that blacklisting only files and folders that are already available in your Dropbox account would result in expected results. If you add data to your local Dropbox setup that isn't whitelisted while the whitelisting script is on the run, there is a possibility that your data may get partially synced and partially blacklisted. Clearly an undesirable state. This happens due to blacklisting of partially synced non-whitelisted data which is bound to occur at regular interval of time.
This leaves us with only two options for an effective whitelisting scheme in cases where newer data added locally needs to be blacklisted:
- To wait till two way dropbox sync completes before starting to whitelist. But this clearly isn't preferable because it would mean syncing all the data both ways i.e., from client to server and vice-versa which could be in Gigabytes.
- Another approach would be to open a single way sync i.e., add data added locally to the whitelist, allow it to sync completely to your Dropbox account and once it is synced completely, remove it from your whitelist resulting in it to be desynchronized and removed from your local setup.
Despite the limitation discussed above, the Whitelisting Based Selective Sync scheme may come handy in use cases where user needs to whitelist a few known files and folders amongst a huge stack files and folders that would otherwise have to be backlisted individually.