Mysteries of Dropbox: Property-Based Testing of a Distributed Sync Service [pdf]

I was lead on Syncplicity's desktop client. File synchronization has a myriad of corner cases that are difficult and non-intuitive to think through; and non-programmers often thoroughly underestimate just how difficult these are to anticipate and mitigate.

The fact that they found bugs that rely on sensitive timing doesn't surprise me.

Every time I try out a Dropbox competitor, I keep coming back to Dropbox. I admit I'm intensely bias, but every other file sync service seems to struggle with things like:

- quickly synchronizing small changes in very large files

- handling a very large number of files to begin with

- renaming many small files and directories in quick succession, especially if subsequent renames happen before the system has fully synced

Anything written by John Hughes is worth a read. He also also wrote quickcheck.

So from what I am seeing in this with a brief look over it, the only cases in which data loss seemed to occur were when two clients were editing the same file temporally close to each other? I.e. you end up creating something similar to a git merge conflict, which cannot be solved automatically well, and thus can generate loss of data.

There was a discussion of a self-built dropbox on the frontpage (https://news.ycombinator.com/item?id=47673394). This is just to show that dropbox is thoroughly tested for all kinds of wierd interactions and behaviours across OS using a very formal testing framework.

Great paper! I’m glad I avoided OwnCloud after discovering how much of a hot PHP mess it is (and that it was about 10x slower for LAN sync than Seafile on a same machine).

I would love to have all the file sync solutions tested with this suite.