Flickr Accidentally Deletes a User's 4,000 Photos and Can't Get Them Back
61–70 of 93 posts
Re: Flickr Accidentally Deletes a User's 4,000 Photos and Can't Get Them Back
#62Re: Flickr Accidentally Deletes a User's 4,000 Photos and Can't Get Them Back
#63I keep hearing about this coming up, yet no one ask talked about why the data is irretrievable. What it implies is that the internal tool(s) that the support staff uses was designed to do deletion instead of status changes. I imagine they have a web interface that fires off some backend script which a) runs sql deletes on an account ID and all tables and b) fires off scripts that physically deletes all photos across…
I can see why Flickr might engineer things this way. Most of their users don't pay (granted, this guy was a pro user). Deleting images when an account is deleted saves money.
Re: Flickr Accidentally Deletes a User's 4,000 Photos and Can't Get Them Back
#64"This wasn't much compensation considering Flickr Pro costs $24.95 per year, and Mr. Wilhelm has already received a year's worth of Pro through his participation in some events and competitions.*" what else could flickr have offered to compensate?
I would have asked for something closer to a full refund and possibly a longer, if not lifetime, term of free usage. It's obviously expensive for Flickr to offer something like this but I mean they accidentally deleted 5 years of a paying customers work. I think a refund is the bare minimum.
Now they've made a mistake, and have refunded this years payment and added future access for free. They have done more than 'the bare minimum'. It might be good PR to refund previous years' fees, but they were at the time provided in good faith and competant manner; there is no 'fair exchange' reason to refund them.
Re: Flickr Accidentally Deletes a User's 4,000 Photos and Can't Get Them Back
#65I keep hearing about this coming up, yet no one ask talked about why the data is irretrievable. What it implies is that the internal tool(s) that the support staff uses was designed to do deletion instead of status changes. I imagine they have a web interface that fires off some backend script which a) runs sql deletes on an account ID and all tables and b) fires off scripts that physically deletes all photos across…
Re: Flickr Accidentally Deletes a User's 4,000 Photos and Can't Get Them Back
#66Re: Flickr Accidentally Deletes a User's 4,000 Photos and Can't Get Them Back
#67(Not to mention the Flickr API has a KNOWN ISSUE with the search that has a fix ETA of several WEEKS! http://www.flickr.com/help/forum/en-us/72157625560721827/)
Re: Flickr Accidentally Deletes a User's 4,000 Photos and Can't Get Them Back
#68"This wasn't much compensation considering Flickr Pro costs $24.95 per year, and Mr. Wilhelm has already received a year's worth of Pro through his participation in some events and competitions.*" what else could flickr have offered to compensate?
I would have asked for something closer to a full refund and possibly a longer, if not lifetime, term of free usage. It's obviously expensive for Flickr to offer something like this but I mean they accidentally deleted 5 years of a paying customers work. I think a refund is the bare minimum.
Re: Flickr Accidentally Deletes a User's 4,000 Photos and Can't Get Them Back
#69Earlier quoted context omitted.
It's an engineering decision - Flikr has to host a large amount of data for very little cost, since most users aren't paying. Space isn't cheap by the Petabyte! The design for a system where you had multiple redundant copies of all the data and could roll back any changes to the data set is different - and would cost a lot more.
Here is what I don't understand. They have multiple redundant copies in case of unlikely scenario of disaster, but they have no copies or protection in case of quite likely scenario of operator error. This seems backward to me. EDIT: I don't believe that Yahoo! Flickr does not have a way to recover these things. Or I'm completely wrong.
For a single account it's more of a pita.
Retrieving all the datas associated with one account, put it in a format readable from the production environment and recommit all the changes while dealing with the potential errors and inconstencies seems quite a huge deal.
Messing unrelated data in the process would also be a nightmare.
Of course, not deleting anything from the start wouod be the way.