Using Dropbox The Unix Way
Using Dropbox The Unix Way
Some time ago I created a network drive interface to Dropbox called<br>dbxfs. There’s no<br>sophisticated syncing logic in it (unlike in the official application,<br>should know). It’s more or less a straightforward FUSE interface to<br>the Dropbox API with some caching to make it less painful to use. It<br>works well for large streaming files and relatively small files. For<br>accessing large files at random, it works less well. For writing files,<br>it’s a pain. Do not start editing source code on this file system and<br>most certainly do not run git on this file system, it’s<br>not fun. On the other hand, you get on-demand access to all of your<br>Dropbox without having to download it first and use hard disk space.
I never thought about making writing files less painful because<br>I never really needed it. It would also just make both the code and the<br>user interface guarantees significantly more complex. The official Dropbox<br>application already exists for that use case. Recently though, a user<br>got in touch with me about the slowness of writing to dbxfs and this got me to<br>think a bit about the problem.
I thought: what if, instead of modifying dbxfs, there was a separate<br>utility that transferred or synchronized changes from one file system to<br>another? That way the user could do all their work on a fast local disk<br>and then run that utility in the background to do the slow syncing to<br>their directory on dbxfs.
It turns out we already have a couple of well-established options for<br>synchronizing directory trees: Rsync for one-way syncing and Unison for<br>two-way syncing. In most cases Rsync will be sufficient but if you’re<br>working with other people, you will want to reach for Unison.
You can use Rsync to do one-way syncing to dbxfs like this:
rsync --recursive --checksum<br>You can use Unison to do two-way syncing to dbxfs like this:
unison -fat -fastcheck false<br>Note that in both cases we check for file equality using the contents<br>of the file instead of using mtime and size as usual. This is because<br>the Dropbox API doesn’t provide a way to modify the mtime of a file<br>after it has been written. You can run these commands continuously in<br>the background by looping them in a shell script or setting up a<br>background service.
By attacking the problem this way, dbxfs gets to stay simple and we<br>get to benefit from all the effort that has already gone into existing<br>sync tools. It’s a win-win, a positive-sum game if you will. This is the<br>Unix philosophy in action: enable the user to combine relatively simple<br>tools focused on distinct functionality to extract richer functionality<br>than the sum of their parts would provide.
These tools have been around for decades at this point so technically<br>none of this should be a surprise. Admittedly it was for me because I<br>always thought of file syncing as a way to get up to date with a<br>server after being offline for a while or to collaborate with others. I<br>didn't think of file syncing as a technique to hide the latency of working<br>on a slow file system. The way that dbxfs fits nicely within the Unix<br>paradigm helped to reveal that.
Rian Hunter<br>2026-05-30