Hacker News Reader

Comment by TallGuyShort | Hacker News Reader

This would break so many scripts. In such environments, surely it would be preferable to transparently implement "trash can" functionality behind RM transparently? (As on commenter on that site mentioned). Rather than unlinking, in some circumstances it would transfer the data (or rename it - I know `delete` in DOS used to just change the first character in the name to ?, which has hacky but fast and enabled utilities like `undelete`) to a recoverable repository.

View on HN

Ahhhhh this answered a question I had when I was about 7: why couldn't I undelete the first character?

'safe rm' or a version of rm which doesn't actually delete stuff is pretty easy. The tough bit it lets say the user creates loveletter.txt, edits it, gets pissed off, rm's it. Now they create it again, edit it again, and remove it.

The simplest implementation fell out of NetApp snapshots, but the next best thing was converting rm to essentially run a directory repostitory (at the time sccs but more modern ones would no doubt use git or something) and each 'rm' was a commit, push followed by removal of the file.

Running it on a live system (in the 90's) it slowed the build way down (removing old object files in 'make clean') but it gave us a way to recreate any state from scratch :-).

In BOFH mode you say "Gee that sucks, next time don't delete files you want to keep."

If they create a new version of a deleted file, why wouldn't that just be treated as an entirely new file? If the rm trashcan altered the filename (like, say, appending the time stamp of deletion) upon "deletion", that would avoid name collisions. Or just do like OS X and append -0, -1, etc.

If you're interested in a real-world example, Purdue University did exactly that, at least for a large portion of the systems they ran, back from 1995 to at least 2000. It was ok.

Here's a page explaining the "entomb" system they had.

http://docstore.mik.ua/orelly/unix/upt/ch23_09.htm

I made such a wrapper for myself [1] after accidentally removing lots of photographs. It uses LD_PRELOAD trickery to achieve its goal. It's in a very early stage but I'm working on it.

[1] https://github.com/grn/careless

Did you read the article?

... yeah? Do you have an actual point to make now? All of his suggestions are very fundamental changes that will break a lot of uses of rm. On the surface they seem to handle your typical users, 'rm -rf ...' but rm's behavior has been an assumed standard for a LONG time. Aliasing it is a baad idea.

Do you have an example of how aliasing could break a script?

why would a rm wrapper, with move to trash behavior by default, break scripts?

Simply replacing 'rm' with a no-op or error command (or removing it entirely) would break scripts. Trash can would not.

You're right directly it wouldn't break scripts; a whole bunch of stuff starts breaking once the disk fills though.

It wouldn't necessarily - it just has to be 100% transparent. A simple alias would probably break a lot of scripts, but if you were very thorough or provided an entirely separate tool for users - that's what I'm suggesting would do this. In reality, I was really just thinking allowed - I think rm's fine as it is. To do this while overcoming the shortcomings I mentioned in DOS's simple approach requires a system more complex than the original problem is worth, IMO.

I've seen a script that uses flock and rm, it would break.

Reply on news.ycombinator.com