Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Flickr Accidentally Deletes a User's 4,000 Photos and Can't Get Them Back

observer.com

Post reply on HN
Print view View original

81–90 of 93 posts

Re: Flickr Accidentally Deletes a User's 4,000 Photos and Can't Get Them Back

#81

Post by phaylon »

abscondment wrote: post #45
potatolicious wrote: post #32

Earlier quoted context omitted.

> "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 all servers." Neither should happen. You never actually delete rows from your tables. You mark them as deleted, sure, but the data needs to be able to come back. Space is cheap, there are simply very few cases where outright deletion from a DB table is warranted. I have a…

I bet that in cases of copyright infringement a logical delete isn't legally sufficient. Sure, you can leave the database pointers in place... but you're going to need to actually remove the infringing content. In that case, at least, a true delete tool would be needed. Like any Internet discussion about copyrights or other people's backend scripts, this is all purely speculative.

Also, depending on the country there might be specific privacy laws that matter.

Re: Flickr Accidentally Deletes a User's 4,000 Photos and Can't Get Them Back

#82

Post by pilif »

The real dilemma is that as a service, you can't do it right. If you keep the data around and just mark it as deleted, the EFF will post articles about you violating the users rights for privacy and control of their data.

And if you delete the data, then $publication will write articles about you being unable to restore it.

Take the Facebook "account disable" feature as an example. In the context of this article here, it was sold as a "good" feature (so as something that Flickr should have too).

But this exact same feature was all over the press a year ago as something really bad and just showing how Facebook just doesn't want to let you go.

So. What is it now?

Personally, just flagging for deleted and living with the privacy concerns might be the better option because there are potentially more people deleting data by accident (or have it accidentally deleted) than there are people too concerned about privacy to use the service.

Also, users concerned about privacy just won't be users whereas users who just lost their data were users and now aren't, so that's a net loss compared to the users not joining.

Re: Flickr Accidentally Deletes a User's 4,000 Photos and Can't Get Them Back

#83

Post by xyzzyb »

InclinedPlane wrote: post #73
dtc wrote: post #72

Earlier quoted context omitted.

Could you point me to some of the rabid competition that might offer a similar pricing model?

Flickr's main competition isn't with services that have feature parity with them, it's more with the growing list of free image sharing sites. Imgur, twitpic, facebook, picassa web, even dropbox. Flickr's value add is rapidly becoming smaller and smaller, which could very easily undermine their business model.

Exactly. I used to have a flickr account but since dropbox/facebook came along if I want to share anything it goes in dropbox (public) or facebook (public, but it's easy for my family to see the pics).

Re: Flickr Accidentally Deletes a User's 4,000 Photos and Can't Get Them Back

#84

Post by xyzzyb »

iwwr wrote: post #17
lwhi wrote: post #7

I think this is a huge problem with all cloud services. As we start to rely on cloud providers to look after our data, we need to either become more educated (and proficient) by creating regular backups ourselves (which kind of makes the idea of managed cloud services defunct imo), or be in a position where we can individually sue for damages incurred by negligence on the part of the service company in question. So m…

A single service, even a cloud, is still a single point of failure. Diversify your backup strategies. Indemnification is likely going to push prices up further, making cloud non-competitive compared to traditional storage. Still, I feel a lot of old technology is merely being relabeled. Today everything that stores data remotely is called a 'cloud'. We may yet see small NAS units relabeled as 'private micro-clouds".

The problem here is that the photographer lost data that he had no way of backing up. His photos are fine, his online collections, uris, and social networking are all gone and only existed on flickr's servers.

Re: Flickr Accidentally Deletes a User's 4,000 Photos and Can't Get Them Back

#85

Post by T-hawk »

potatolicious wrote: post #32
geuis wrote: post #31

I 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…

> "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 all servers." Neither should happen. You never actually delete rows from your tables. You mark them as deleted, sure, but the data needs to be able to come back. Space is cheap, there are simply very few cases where outright deletion from a DB table is warranted. I have a…

> You never actually delete rows from your tables. You mark them as deleted, sure, but the data needs to be able to come back. Space is cheap, there are simply very few cases where outright deletion from a DB table is warranted.

This comes with a cost, and it's not a small one. Every single query that ever touches this table, in every single piece of code owned by the company, written or maintained by every single developer (consultant or transient or offshore, none of which ever got training sessions on this requirement) needs to be enhanced to respect "where isDeleted true".

It's well understandable if the expected cost to recover after the fact from an occasional issue is smaller than the cost of implementing and maintaining that in the first place.

Re: Flickr Accidentally Deletes a User's 4,000 Photos and Can't Get Them Back

#86

Post by jgarmon »

there wrote: post #11
jamesjyu wrote: post #6

Time for backupify.com?

anyone know of anything like that for downloading the data locally? backing up data in the cloud to another place in the cloud just seems stupid. i've seen some flickr-specific backup scripts that just dump all of the images to a directory, but they don't preserve titles, dates, sets, collections, tags, etc.

Backupify allows you to download the data you backup to their cloud servers onto your local PC, and the base level of the service (2GB online backup) is free.

Re: Flickr Accidentally Deletes a User's 4,000 Photos and Can't Get Them Back

#87

Post by jgarmon »

angrycoder wrote: post #57
lwhi wrote: post #7

I think this is a huge problem with all cloud services. As we start to rely on cloud providers to look after our data, we need to either become more educated (and proficient) by creating regular backups ourselves (which kind of makes the idea of managed cloud services defunct imo), or be in a position where we can individually sue for damages incurred by negligence on the part of the service company in question. So m…

Well, there's the next startup idea, a backup service for cloud services. There is a joke in there about putting a cloud in your cloud, but I am not sure how that meme goes.

That service exists: http://www.backupify.com/

Re: Flickr Accidentally Deletes a User's 4,000 Photos and Can't Get Them Back

#88

Post by smackfu »

potatolicious wrote: post #32
geuis wrote: post #31

I 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…

> "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 all servers." Neither should happen. You never actually delete rows from your tables. You mark them as deleted, sure, but the data needs to be able to come back. Space is cheap, there are simply very few cases where outright deletion from a DB table is warranted. I have a…

You never delete, and then people bitch that they can't really leave the service. See: Facebook.

Re: Flickr Accidentally Deletes a User's 4,000 Photos and Can't Get Them Back

#89

Post by derobert »

T-hawk wrote: post #85
potatolicious wrote: post #32

Earlier quoted context omitted.

> "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 all servers." Neither should happen. You never actually delete rows from your tables. You mark them as deleted, sure, but the data needs to be able to come back. Space is cheap, there are simply very few cases where outright deletion from a DB table is warranted. I have a…

> You never actually delete rows from your tables. You mark them as deleted, sure, but the data needs to be able to come back. Space is cheap, there are simply very few cases where outright deletion from a DB table is warranted. This comes with a cost, and it's not a small one. Every single query that ever touches this table, in every single piece of code owned by the company, written or maintained by every single de…

No, that's what views are for.

A sane approach would be to do all your table access via views, and the view definitions have the 'where is_deleted = 0' or whatever. Then your database handles it.

Updates to the view work as well, in pretty much every database system, including MySQL even.

Re: Flickr Accidentally Deletes a User's 4,000 Photos and Can't Get Them Back

#90

Post by danudey »

bl4k wrote: post #66

This is why I never have a DELETE call anywhere in my app or admin code. I always mark as deleted (there are performance improvements in this for some databases as well)

I've worked at several places where the strategy is 'never delete, just mark as deleted'. Your database tends to grow pretty fast, but you never have to defragment your index or tablespace.
Post reply on HN