Using Dropbox The Unix Way

Some time ago I created a network drive interface to Dropbox called dbxfs. There’s no sophisticated syncing logic in it (unlike in the official application, I should know). It’s more or less a straightforward FUSE interface to the Dropbox API with some caching to make it less painful to use. It works well for large streaming files and relatively small files. For accessing large files at random, it works less well. For writing files, it’s a pain. Do not start editing source code on this file system and most certainly do not run git on this file system, it’s not fun. On the other hand, you get on-demand access to all of your Dropbox without having to download it first and use hard disk space.

I never thought about making writing files less painful because I never really needed it. It would also just make both the code and the user interface guarantees significantly more complex. The official Dropbox application already exists for that use case. Recently though, a user got in touch with me about the slowness of writing to dbxfs and this got me to think a bit about the problem.

I thought: what if, instead of modifying dbxfs, there was a separate utility that transferred or synchronized changes from one file system to another? That way the user could do all their work on a fast local disk and then run that utility in the background to do the slow syncing to their directory on dbxfs.

It turns out we already have a couple of well-established options for synchronizing directory trees: Rsync for one-way syncing and Unison for two-way syncing. In most cases Rsync will be sufficient but if you’re 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 <local_folder> <remote_folder>

You can use Unison to do two-way syncing to dbxfs like this:

unison -fat -fastcheck false <local_folder> <remote_folder>

Note that in both cases we check for file equality using the contents of the file instead of using mtime and size as usual. This is because the Dropbox API doesn’t provide a way to modify the mtime of a file after it has been written. You can run these commands continuously in the background by looping them in a shell script or setting up a background service.

By attacking the problem this way, dbxfs gets to stay simple and we get to benefit from all the effort that has already gone into existing sync tools. It’s a win-win, a positive-sum game if you will. This is the Unix philosophy in action: enable the user to combine relatively simple tools focused on distinct functionality to extract richer functionality than the sum of their parts would provide.

These tools have been around for decades at this point so technically none of this should be a surprise. Admittedly it was for me because I always thought of file syncing as a way to get up to date with a server after being offline for a while or to collaborate with others. I didn't think of file syncing as a technique to hide the latency of working on a slow file system. The way that dbxfs fits nicely within the Unix paradigm helped to reveal that.

Rian Hunter
2026-05-30