Dropbox Bug Can Permanently Lose Your Files

127 of my files in Dropbox are now gone forever, due to a bug where files were "updated" to be 0 bytes, and Dropbox lost its previous copy of the file.

2 other files (precious family photos) were also affected, but it happened recently enough to be recovered manually by Dropbox engineers. 23 other files were also turned to 0 byte dust, but Dropbox kept its version history of these and I could revert them to their original version.

Check whether you've been affected (on Mac or Linux) by running this command in a Terminal, it'll spit out a list of 0-byte files to a text file on your desktop.


find /path/to/your/Dropbox -size 0 -type f > ~/Desktop/zero-byte-files.txt

Important: Make sure you sanity check the list. Some systems have hidden 0-byte files, such as Macs' "Icon\r", that are expected and normal.

If you find any that look unexpected, let Dropbox know, and reference this blog post to them so they can connect it with the issue I reported.

I've included my correspondence with Dropbox on the issue below. They've been very nice about it, and are looking into it, but this is a very serious bug. Because they don't know what the bug is, potentially anyone could be affected. I'll update this post if they find a fix.

Update: Some folks on Hacker News, and Matt Holden of Dropbox in the comments, have raised the possibility of filesystem corruption, particularly because of a recently reported ext4 bug. I do use ext4, so this can plausibly explain why my files were 0-byte'd in the first place, and why others have reported finding 0-byte'd files.

I also do not use Packrat, a premium Dropbox feature that stores version history for longer than 30 days, so this could plausibly explain why my 127 files that had been 0-byte'd months ago no longer have a version history of before then. I wasn't aware of the 30-day window.

However, these do not plausibly explain why the 2 manually recovered files that had recently been 0-byte'd, well within the 30-day window, showed no pre-0-byte version history, and required the assistance of Dropbox engineers.

It could be that the bug here has nothing to do with their desktop client - it could be a version history bug in the web frontend that affects some recently edited files. If that's the case, then that still needs to be fixed, so that people in my position can recover files their disk corrupted before they pass out of the 30-day window. It's only by finding and fixing that website bug that Dropbox can say with confidence that there's no desktop client bug.

Update 2: A report by someone who is on OS X, uses Packrat, but has lost 70 files they can't recover.

Original correspondence

Eric Mill, Oct 20 05:50 pm (PDT):

Hi,

I recently wiped my hard drive and reinstalled my OS (clean upgrade from Ubuntu 12.04 to 12.10). I had been running Dropbox on the old OS. When I installed Dropbox on the new OS, almost everything went very smoothly. However, for some unknown reason, 25 files were "edited" to become 0-byte files.

This took place over 3 "events", at 3:49 PM, 5:31 PM, and 5:45 PM that afternoon:
https://www.dropbox.com/events/[redacted]
https://www.dropbox.com/events/[redacted]
https://www.dropbox.com/events/[redacted]

As far as I know, nothing I did caused these to happen. I didn't interact with these files, and in fact, I took care not to make any destructive actions in my Dropbox folder during the long syncing process. I believe these are bugs in Dropbox's syncing logic, but I have no idea how to reproduce it, or what common thread ties these files and events together.

I am able to restore each file from Dropbox's version history, though the user experience for this process is pretty annoying - I have to navigate through the file system for each one. There's no way to jump from an "event" screen that lists the affected files to a file's version history screen.

In general, I'm pretty happy with Dropbox, but this was a pretty alarming bug. I hope there's something you can do to look into why it happened.

Thanks,
Eric


Ridwan - Dropbox Support, Oct 22 05:11 pm (PDT):

Hi Eric,

Terribly sorry about the delayed response on this support request. In reviewing your account you appear to have restored most of these files via the web interface (I restored one extra).

Is there anything further I can assist you with?

I'm not aware of any bugs in the client syncing process at this moment, but I'll pass your case along to our engineering team. Hope this helps! Please let me know if I can be of any other assistance.

Best,
Ridwan


Eric Mill, Oct 23 07:37 am (PDT):

Yeah, there is one other piece of assistance I need - in restoring the files one by one, I noticed there were two that seem to have lost their history entirely:

https://www.dropbox.com/revisions/[redacted]
https://www.dropbox.com/revisions/[redacted]

These two files were the first two marked as "Edited" in the third Dropbox event along with a bunch of other files, the rest of whom have an earlier version I could restore. These two do not, yet they definitely had an earlier version that was not 0 bytes. Dropbox describes the event as "Edited", which clearly implies there was an earlier version.

Again, I have no idea why these 25 files, among my entire Dropbox, were affected, or why these 2 were affected differently from the other 23. These 2 files are now lost to me.

I would ask that you take this as a serious bug report. Even if your engineering team were to write off my original report of 25 files being 0-byte'd as my own human error (which it wasn't), the state of these two files indicate an undeniable bug in Dropbox's software (which in turn strongly suggests that all 25 were affected by a Dropbox bug).

If you can restore my files somehow, that would be greatly appreciated. Thankfully, these are just a couple of random photos - but I have other, more irreplaceable files contained in Dropbox, and if I were to lose them I would be very upset.

-- Eric


David M. - Dropbox Support, Oct 23 05:30 pm (PDT):

Hi Eric,

I've reported this to our engineers and they are taking a further look into the issue. To help troubleshoot the issue can you run the following in Terminal:

find /home/eric/.dropbox_actual/Dropbox -size 0 > ~/Desktop/zerodump

This should generate a text file on your Desktop. Can you attach that file to your reply so we can see if there are any additional files that are 0 bytes in your Dropbox folder. Please also note there may be some false positives as some applications will create 0 byte log/temp files.

Additionally, can you let us know of any system events that may have occurred during the time frames for those changesets?

Thanks!

Best,
David


Eric Mill, Oct 24 07:07 am (PDT):

Hi David,

Thank you for the prompt response. That's a good suggestion, I ran the command and have attached the file. I should have thought of that myself.

There are more files than I expected listed as 0 bytes. The one that's marked as deleted and is in the dropbox cache folder is one that I deleted myself on the same day as the events in question, before I realized what was going on. Many of the rest are apparently from earlier in the year - for example, one is this, from May 20th:
https://www.dropbox.com/revisions/[redacted]

May 20th is somewhat near when I last upgraded Ubuntu, but I'm pretty sure I did that much earlier in May, soon after Ubuntu's release. This one also lacks a previous version to restore, which is alarming.

I don't know what specific system events would have transpired during the events in question, either in May or October. In October, the 3 events I originally referenced occurred throughout the late afternoon, during the hours after installation of Dropbox in which it was syncing ~11GB of data down to my laptop. During this time, I was re/installing other drivers and software, occasionally rebooting, and configuring things like my /etc/fstab and my /etc/X11/xorg.conf files.

The only thing I can think of that might have been related is that, somewhere in the middle of that, I added the user_xattr flag to the partition on which my Dropbox lives, and rebooted (which caused a remount). My understanding is that the user_xattr flag is a pretty harmless option, that allows applications that care about such things to add arbitrary filesystem attributes.

Unfortunately, I don't have system logs from that time - because I have an SSD, I mount my logs directory into RAM (to minimize disk writes) and it gets wiped on every reboot. Still, if you have any other questions I'm happy to try to answer them.

-- Eric


David M. - Dropbox Support, Oct 25 02:48 pm (PDT):

Hi Eric,

I was able to have our web team recover the two files:

https://www.dropbox.com/revisions/[redacted]
https://www.dropbox.com/revisions/[redacted]

Unfortunately, it looks like the files that were previously 0 byted can no longer be recovered as their previous versions were removed from our servers as the events occurred in June. I sincerely apologize for this file loss.

Thank you for the additional information you were able to provide about the events, I'll be continuing to follow up with our engineering team to try and find the root cause of this issue. I'll let you know as soon as we have any news.

If you have any additional questions or concerns please let me know.

Best,
David

Sure, leave a comment:
  1. idont

    If sectors are damaged on your disk, this can happen... If the source is corrupted, the offsite backup can not fix it. I lost a few familiy pictures because of this... :( Since that mini-drama, I only use minimum RAID 1 configuration where my files are stored + I use offsite backup (mozy).

  2. stacy

    I assume Time Machine or some other incremental backup solution would be a good supplement? I am hard core about backups since losing some photos of my kids years ago.

  3. scain

    I use Dropbox for synchronization among different machines and it is great for what it is. However, as you've discovered file synchronization is not a substitute for a good backup. I personally use CrashPlan for automated backups because it works on Windows, Linux and OS X and is well worth the price ($0 if you back up to your own devices).

  4. Kelso

    Pack Rat Dropbox extra subscription allows you to recover any deleted file, regardless of when it was deleted, would it solve the issue?

  5. JohnB

    Nice catch, and thanks for sharing! I checked my own Dropbox content and found a good 20+ files suffered the same fate. I had redundant backups of almost everything, so I don't believe anything was lost. This time. I submitted a support ticket to Dropbox with my information. Hopefully it will help them resolve the issue.

    I sync my data between two computers, a Win7 machine and a Lubuntu laptop. The laptop selectively syncs just a few folders, but all of the corrupted files were included in that list. Not sure if the same is true for anyone else, but it's more info for the Dropbox folks to chew on.

  6. Nodovitt

    How do you check if the files are missing?

  7. Eric

    @idont - Dropbox's own website dropped the older versions of these files, that it once had on record, so the issue could not just be my disk. Dropbox's engineers were able to manually recover two files from their servers that, according to the website frontend, didn't exist in more than 0 byte forms.

    @stacy, @scain - I don't use Dropbox for backup of all my things, and not my most precious/personal things. For those, I back them up myself to my webserver, though I haven't set up an automated system to do this. (I'm looking at duplicity (http://duplicity.nongnu.org) to do this.)

    @Kelso - I do have deleted file recovery enabled. For 23 files, I was able to use this facility to restore them myself. For the ones that are lost, their entire version history is just one, 0-byte version.

    @JohnB - Glad you were able to catch it. Feel free to reference my account by email (konklone@gmail.com) if you want.

  8. Eric

    @Nodovitt - if you're on Mac or Linux, run the command I listed above:

    find /path/to/your/Dropbox -size 0 > ~/Desktop/zero-byte-files.txt

    Replace "/path/to/your/Dropbox" with the actual path to your Dropbox.

  9. Matt Holden

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

    I just wanted to let you 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...) 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).

    Thanks, Matt Holden

  10. Eric

    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.

  11. Techload

    I'm going for a double backup solution now. Thanks for posting this.

  12. SubmarineDeckhand

    I have often wondered about this; never happened but whenever I link a new machine to an account there doesn't appear to be any guaranteed way to optionally select which is to be taken as master in the syncing process the online folders or the new box?

    It is similar with ipods if one isn't aware & careful any work to modify an ipod is lost as soon as it is hooked to a usb port with itunes installed; only option, after much searching first is itunes is master and u can say yes or no to sync. so u have to say no, then use 3rd party s/w to dump ipod contents then copy into itunes and then allow resync.

  13. SubmarineDeckhand

    I have found when I drag and drop any files that they are actually moved and NOT copied unless I make a special effort to ensure the CTRL key is held down on the drag & drop

  14. Bug

    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.

    The thing is, Dropbox should be informing YOU of this, instead of you having to do their job for them.

    Official line: "Nope, no problem on our end."

    Expert user: "Your internal metadata is corrupted."

    (Silence)

    What is an ordinary user supposed to do?

    A backup service needs to actually ensure the integrity of their OWN data, not just plop an extra copy of your file in a single place until the bits rot. De-duped, of course, meaning one bad block can take out tons of files (say, a JPEG header block).

  15. Daniel

    A possible reason why DropBox doesn't have file data for the changes is that the modified time for the files may not have changed. i.e. when the files were zero-bitten DropBox detected the change, then overwrote their most recent entry with the zero-byte version. It's not hard to believe that DropBox use the last modified time as some sort of key in their data structures.

    I've performed the aforementioned test on my computer and have come up with a whole lot of zero-byte files as well. However, I recognise these as all being files that I copied from a Linux computer onto my Mac (Snow Leopard), then into my DropBox (I've never had DropBox installed in Linux).

    It's hard to say exactly where and when these files became zero'd but DropBox seems to think that they have always been zero'd. Possibly there may be an issue with DropBox syncing files that have been "touched" by Linux - hard to think what but these days with extended attributes and such it cannot be ruled out quite so quickly as in the past.

  16. clasqm

    Just a small note: If you run the find command as directed here on a Mac, you can ignore any results like this:

    /Users/clasqm/Dropbox/Family Documents/Icon

    That just means you've put a custom icon on that folder and that is supposed to be a zero-byte file.

  17. StopTheMadness

    STOP with the EXT4 bug madness. The person who reported the EXT4 bug had turned off several safety knobs (ie: non-default settings) and used umount -l and other bad practices. Does Dropbox change EXT4 mounts to nobarrier and journal_async_commit and do forced shutdowns with lazy dismounts? No? Move along then.

  18. G. Cohen

    Just a quick note, Time Drive (https://launchpad.net/time-drive) is a GUI front-end for Duplicity, if it helps. I'm not affiliated with Time Drive, just used to be a user (but not anymore, for reasons not related to Time Drive itself).

  19. Vic

    If you're using cygwin, the find command you cite seems to return all directories too for some reason. Fix this with

    find /path/to/your/Dropbox -size 0 -type f > ~/Desktop/zero-byte-files.txt

  20. Florian Harbecke

    You Should try adding -type f option to only list files. Directories are always 0 byte ;)

  21. elGuapo

    Why are you relying on your "precious" files sitting on someone else's free service? 1 version sitting on DropBox is not a "backup" by any stretch of the imagination. "Backup" means there are 2 copies in 2 different locations.

  22. stefan

    I had the same issue (files zeroed out). I'm mostly using Dropbox on MAC, and it seems it was a rarely used Linux (Ubuntu) Dropbox client that zeroed out the files.

    Some of them I could recover (I realized fast enough), but for others I realized too late in order to try and take advantage of Dropbox's 30 days history.

    Until the issue is understood I will run a daily cron job that looks for zero files and emails me if it finds any.

  23. dgw

    I ran the command in msysGit's Bash shell and found a bunch of zero-size files. Most of them are system/application files that are expected to be empty, but a few files transferred from a college FTP server appeared in the list. At least one of them was zero-sized at backup; that page on the website is completely blank. While my results don't confirm this bug, they are odd, as I haven't noticed those zero-sized files since they were backed up from the FTP server two years ago.

  24. shadow land

    ZFS

    ftw?

  25. Laura

    I "restored/fixed" my 0-KB folder.

    1.) Paused Time Machine 2.) Increased my Dropbox storage quota from 200 to 500 GB 3.) Added Packrat feature 4.) Removed ALL Windows-incompatible characters from my file names: https://www.dropbox.com/help/145/en I don't know how, but my files are back in my folder and synced. I use Dropbox 1.4.7 - synced between MacPro & 2 PCs I typically download RAW files from my camera to my desktop, edit, then drag into Dropbox. I noticed the O-KB folder sometime after importing via 'Camera Upload' feature. This feature may or may not be involved in 0-KB error. Good Luck!

  26. Ross

    I'm experiencing a variant of this bug at the moment. I added a blackberry phone to my account and started using the photo upload feature of the official app. The first photo worked fine, but every one since appears as zero size with no history (even though I pay for the unlimited undo "packrat" feature). Thankfully the photos are still on the phone because unlike a desktop, it doesn't continuously sync with the servers.

  27. Yorik

    I'm experiencing exactly the same bug (installing dropbox on a new pc, on an ext4 partition on a brand-new HD), a lot of files have been "wiped" during the restore process and have 0-byte size... Contacting Dropbox now, I hope they can restore them for me... It's pretty scary...

  28. Ross

    I do have a linux ext4 machine attached to my dropbox, so wandered if that could be part of the problem. I tried disabling sync on that machine and uploading a new photo from the blackberry, but it still appears as a zero size file (checked using the web interface).

  29. Yorik

    Dropbox support told me the new 1.7 version should fix this problem: https://forums.dropbox.com/topic.php?id=95594

  30. C Bhushan

    This particular observation is not related. But it looks similar.

    http://flukylogs.blogspot.com/2013/03/dropbox-bug.html

  31. Justin

    I also lost my entire dropbox, using the linux client. I clean installed from 12.10 to 13.04. My dropbox was pointing to /usr/dropbox/Dropbox (so it would be on my Hard drive not my SSD). On first boot, dropbox of course couldn't find that directory, so I recreated it. It was of course empty. Dropbox instead of syncing my files down, decided I'd deleted 3,700 files from my dropbox. Every single file, the web history reports them as deleted. I've filed a request to get them back a few days ago and have yet to get a response, but be very careful with the linux version of Dropbox. And don't rely on dropbox as your sole backup method.