Hacker News new | ask | show | jobs
by sean_lynch 4919 days ago
While I can't comment on this specific case, I do want to say there is a tremendous amount of rigor (and layers of protection) to ensure the end clients are resilient to misbehaving computers and do the right thing. For example, you shouldn't have to worry about the clock being accurate as it has no bearing on the final sync state.

Just to dive in a bit for the HN crowd: We base the changes that should be applied to your Dropbox on whether the client has successfully synced the previous version of the file. The server doesn't allow the client to apply changes unless the client is fully up to date. And in the case of deletions, the desktop client is only permitted to issue deletes to files that have been successfully created on disk and then later deleted.

We also have a proper support team to catch things that fall through the cracks, and if you have issues, you should reach out to them first (and as soon as you notice; their ability to fix things becomes harder the more changes you make to your account).

Again, not commenting on the above issue, but I did want to point out that we take the integrity of your data very, very seriously.

3 comments

I've replied to this elsewhere, but let me reiterate here:

sean_lynch is not kidding about Dropbox's support staff. They are great, very helpful, and according to my colleague, are very serious about trying to restore everything. The issue he had was a software bug, and apparently some things are problematic to restore because of other technical reasons, but Dropbox has been very helpful.

And to make this clear - they were very helpful when this happened last week, before this thread - you don't need to write a blog post to get their help and attention.

Client rigor doesn't help with server failure this severe.

The guy lost everything because a temporary team membership was revoked. And now you're coming back to talk about your rigor, and how you catch things that fall through the cracks.

This really comes off, to me at least, like LinkedIn did when after their breach and it was revealed they weren't even salting passwords, they tried to brag about their security, as a way to step around owning up.

I think you should consider this tone very carefully.

Completely disagree. I found no problems with the tone here. Instead, you have an insider who shares a few implementation details to give us an idea about the depth at which they go to prevent data loss failures. I saw nothing in his post as "bragging".

The guy lost everything because a temporary team membership was revoked.

What would you like him to do, apologize profusely and robotically without knowing the details of this incident? Dropbox is a decent-sized organization and I am pretty sure they have guys already responsible for addressing specific issues like this. To expect every employee to know details of every issue seems unreasonable.

> What would you like him to do, apologize

If you had stopped there, I'd have said yes.

.

> To expect every employee to know details of every issue

I ... had no such expectation?

John - take a second to read the comment. He was providing feedback on a scenario in which a machine which had not been powered up in a long time apparently deleted files because they were not present. The Dropbox model does not allow this - you can only delete files that are already on your hard disk. This, is what he was trying to explain to the parent poster. His tone was entirely appropriate.
He's replying to edanm, who had another problem, and not the blog author. His comment is more relevant to edanm's problem and I think it's fine.
... whoooooooops.

Sorry. Thanks for explaining. `:(`

I believe he was referring to the claim that switching on an old computer that hadn't been synced in awhile deleted tens of thousands of files. Not the original post.
Quite right. My bad.
Let's say he's using packrat in this scenario, if he chooses to restore folder X, will it restore all the files ever in this folder with packrat?