Hacker News Reader

Comment by matt_holden | Hacker News Reader

(Hi all, I'm the PM for the Dropbox desktop client team.)

I just wanted to let you all know that we take any claims like this really seriously. There aren't any known bugs on the Dropbox side that would cause this, and unfortunately there are potential causes such as hardware errors, filesystem corruption, and other OS issues (including those like http://www.phoronix.com/scan.php?page=news_item&px=MTIxN... which another poster pointed out) that can corrupt data or create zero byte files.

Nevertheless we will continue to look into this just to be sure, and we also work hard to find ways for Dropbox to shield users even when the OS, disk or other components fail (our undelete/file revisions and Packrat are among these).

View on HN

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.

Text of originalgeek's hellbanned(?) reply to this subthread:

  I ran the find command suggested by the OP, 
  and it came up with a long list of files -- all 
  names that I had intentionally and manually deleted. 
  It seems when one of my "other" machines booted up, 
  it put 0 byte files back in their place. A review of 
  the file's history, by clicking Dropbox -> Browse on 
  Dropbox Website shows the original file, the day I deleted 
  it, then a few minutes later, a 0 byte file added back.

Edit: posted because it seemed like the sort of information I'd want if I worked at Dropbox and were looking for clues to the nature of the bug. If this isn't kosher let me know (rather than simply downvoting) and I'll delete the reposted comment, if possible.

Why was this reply hell banned?

The user who posted it presumably ran afoul of a rule (possibly an unwritten one) in an earlier comment. You'd need to dig through his/her comment history to try to figure out what happened.

Sometimes. There is also a flawed system that can auto-hellban people unlucky enough to get a bunch of downvotes on an early comment, before they have a karma buffer.

I ran the find command suggested by the OP, and it came up with a long list of files -- all names that I had intentionally and manually deleted. It seems when one of my "other" machines booted up, it put 0 byte files back in their place. A review of the file's history, by clicking Dropbox -> Browse on Dropbox Website shows the original file, the day I deleted it, then a few minutes later, a 0 byte file added back.

Reply on news.ycombinator.com