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.

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.

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

One of the authors, John Hughes did a talk on property-based testing at Clojure West some number of years back. Worth a watch if you're interested: https://www.youtube.com/watch?v=zi0rHwfiX1Q

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.

Business idea- a file sync software run by a company that promises to fire any employee who suggests adding a "feature."

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.