| Matt, Thanks for posting here. The reason I'm confident that this bug is not due to filesystem errors on my machine's part is because Dropbox's version history for these files has become corrupted. If you read over the details and correspondence, you'll see that Dropbox engineers were able to recover two of my files that Dropbox's version history had reported as only having a 0-byte version. These files were edited recently, within the 30-day window that all Dropbox users, Packrat or not, have version control for. The files had clearly been whole when first synced to Dropbox, but that version was not listed in Dropbox's history, and so I had no power to restore them. Even if my own disk had spontaneously 0-byte'd those files, this should not have caused Dropbox to lose the ability to restore it to its original version. More circumstantially, others are reporting similar issues: https://twitter.com/dangillmor/status/261921738441515009 - https://twitter.com/pc1oad1etter/status/261957001234505728 - https://twitter.com/frr149/status/261957708746469378 - http://news.ycombinator.com/item?id=4704236 - http://news.ycombinator.com/item?id=4704178 - http://news.ycombinator.com/item?id=4704063 - http://news.ycombinator.com/item?id=4704485 It's tough to tell from these small updates whether these users had their files 0-byte'd only locally, possibly by the ext4 bug, or whether they've also verified that it's not recoverable from Dropbox. In addressing this bug report, please specifically address Dropbox's loss of version history. The two files that Dropbox engineers recovered had their version history wiped within the 30 day window. |