Re:How to terminate your worst enemy's Dropbox account for o...
by Dylan16807 on Monday December 24, 2012 @05:52PM
(#4964414)
I read your posts. The constructive parts are minor compared to the derail, and you easily could have avoided the enormous argument. Also, do you really see no downside to the fact that you have basically reimplemented manual sync on top of dropbox? It throws out most of Dropbox's safety features just because they aren't perfect, and throws out half the ease of use.
Right. You didn't obviously read my comments, did you? Maybe you just skimmed them and chose to jump on the band-wagon?
http://news.ycombinator.com/item?id=4963826
I'll quote the most relevant and definitely constructive/useful parts here you don't have to bother with the links if you don't want to. If you do, please slow down and read it all. Then think about the idea of loosing, I don't know, a year's worth of work and blaming someone else for it.
Here it is (reformatted because HN does not have a much-needed block-quote markup):
Do this TODAY and unless you have massive local loss of data you don't have to worry about Dropbox loosing any of your data at all. Not one bit. If that isn't constructive I don't know what it.Then I also said:
In other words, if Dropbox could implement the suggested approach EVERYONE, engineer or not, would be spared of total data loss due to something going on at Dropbox. Local data loss, of course, is still your responsibility.And then, trying to understand further, I asked this:
http://news.ycombinator.com/item?id=4963768
So, I'll say that overall I've been pretty constructive. If anyone adopts my approach of storing their Dropbox folder in an unused drive they are almost guaranteed that Dropbox can't loose their data. That is worth money.
Please point me to a link or blog post with your immediate solutions to this problem. I'd love to compare notes. Maybe there's a better approach. Always interested in learning. I am sure there are lots of people who, tonight, might be interested in adopting your approach to ensuring that accidental data loss by a remote service of any kind does not mean total data loss locally.
Thanks.