Hacker News Reader

Comment by bryik | Hacker News Reader

In the UNIX Hater's Handbook, defenders of rm consider accidental deletion a "rite of passage" and remark that "any decent systems administrator should be doing regular backups" (see page 62). The author's response is funny:

“A rite of passage”? In no other industry could a manufacturer take such a cavalier attitude toward a faulty product. “But your honor, the exploding gas tank was just a rite of passage.” “Ladies and gentlemen of the jury, we will prove that the damage caused by the failure of the safety catch on our chainsaw was just a rite of passage for its users.” “May it please the court, we will show that getting bilked of their life savings by Mr. Keating was just a rite of passage for those retirees.” Right.

I'm surprised how relevant parts of this book are 22 years later.

http://www.vbcf.ac.at/fileadmin/user_upload/BioComp/training...

View on HN

Is there an alternative to allow scripted destructive actions without the risk of deleting important stuff?

Modern OS's will warn you if you try to delete stuff, but you can still ultimately do it anyway, I don't see it as something particular to UNIX.

The only similar problem I had was on windows, 98 I guess, I deleted all my files that weren't readonly by fiddling with a .bat script.

well there's some safe guard checks you can do to prevent the easy abuses like require an additional flag for rm -rf-ing everything in the root or /home/*/, or across device boundaries as some one said.

You can redesign rm so people don't find themselves typing -rf as force of habit.

You can have multiple delete commands: mark as overwriteable if need and remove from 'ls -a', actually delete, overwrite sectors with zeros; like we have in guis.

You can have a permission system that isn't just "this account can do literally anything" or "this account can't do anything"

here's a dumb idea off the top of my head: /etc/rmblacklist.conf autopopulated (by the distro) with a list of files (/boot and the actual bootimage for instance) that requires a GNU style long option --nuke to delete. It's still easily scriptable but you'd rarely ever actually need it and requiring a long option would serve as a double check that you meant it when you did.

Sure it's still possible to --nuke something due to a bug or negligence but I bet it'd cut down on fatal errors. Plus the user could have their own ~/.rmblacklist.conf to guard against particularly persistent dyslexias.

You could even erase the contents entirely if you really think being able to delete root on a whim keeps your kung fu strong.

This isn't a bad idea.

Good to see you fighting the fight with many sensible ideas. I've been posting this one in most responses as it's pretty simple:

https://launchpad.net/safe-rm

Hah! Beat me to the punch by 5 years.

Darn, I didnt notice it was that old. Makes situation even worse for UNIX rm defenders. Like when Trusted Xenix eliminated setuid vuln's mostly by clearing setuid bit during a write w/ admin having to manually reset it. Simple shit. Mainstream response? "Just audit all your apps for setuid and be extra careful in..." (sighs)

You could just make the file immutable and read only:

http://paste.click/qMpmyO

Then remove the immutable flag if needed

Have an immutable filesystem, where "deletes" are recoverable by going back in time. At least until you do a scheduled "actual delete" that will reclaim disk space.

Another option (though last time I tried it, it didn't work..) is something like libtrash: http://pages.stern.nyu.edu/~marriaga/software/libtrash/ Deletes become moves and you can really delete when you like.

Practically speaking, if you're quick an 'rm' isn't totally destructive even without backups. There's a good chance your data is still there on the disk, it's just not associated with anything so it could be overridden at any point. Best to mount the disk read only and crawl through the raw bits to find your lost data (I recovered a week's worth of code this way several years ago).

> At least until you do a scheduled "actual delete" that will reclaim disk space.

And then you "actual delete" is where the data loss occurs :D

Right but if you delete your entire file system there won't be anything to come along and do the "actual delete" so you're safe until some one comes along with a rescue disk or otherwise mounts it to a system that knows how to deal with this.

At the very least when you rm important-file.txt instead of importanr-file.txt you have a chance.

Pre-delete would already hide files from apps and services for them to "fail fast", and actual delete would be just "i'm running fine for two days". Of course this implies that active open files should not be pre-deleted on unix at all (at least not by rm process). Even if you delete the entire filesystem with backups, there will be a chance to boot into recovery mode and undelete everything back. We can even go further and apply small-file-versioning on fs level to prevent misconfig accidents in /etc.

That's very simple and powerful, I can't tell why it is still not implemented today.

My favorite answer to the common interview question: "What was your biggest mistake, and how did you recover from it?" Answer: Back in 1993, I once deleted a critical data file. Fortunately, the AIX host was sitting next to me, so I quickly reached over and flipped the power switch off. The strategy being: writes were buffered and flushed out periodically, so hitting the power switch prevented that last write from hitting the disk. And if this didn't work (and caused more file system corruption), well I would have needed to restore from backup anyway.

That's great. Straight out of an NCIS episode except it actually makes sense this time. :)

There's no reason the Recycle Bin couldn't work for scripting languages, except for lazy OS and language developers haven't bothered to wire-it-up.

https://launchpad.net/safe-rm

Use something like that with scripting. It really is that easy to protect critical stuff with otherwise easy-to-use rm. UNIX has always been resistant to do stuff like this. However, it's architecture makes it fairly easy for developers to do it themselves. That's to its credit.

That attitude was pervasive in both UNIX and C. That other systems avoided common problems of both with little work or penalty shows it's unnecessary today. Yet, the results of that attitude continue to do damage.

The author stretches his analogies substantially. It's nice to see this was happening 22 years ago just like it is nice to see UNIX from more than 22 years ago still being used today.

Edit: i.e. it isn't so nice. Not much progress.

Yeah, I saw the same problem in the NSA backdoor debate where people liken it to brake failures and such. I pointed out repeatedly that computer breaches rarely maim or kill anyone. Usually don't even cost them their jobs or bankrupt their business. Such analogies are strawmen to try to boost their argument with an emotional response.

Reply on news.ycombinator.com