4 ms·

This would break so many scripts. In such environments, surely it would be preferable to transparently implement "trash can" functionality behind RM transparent

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.

conexions 13y ago
Did you read the article?
- TallGuyShort 13y ago
  ... 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.
  - conexions 13y ago
    Do you have an example of how aliasing could break a script?
alperakgun 13y ago
why would a rm wrapper, with move to trash behavior by default, break scripts?
- koenigdavidmj 13y ago
  Simply replacing 'rm' with a no-op or error command (or removing it entirely) would break scripts. Trash can would not.
- tankenmate 13y ago
  You're right directly it wouldn't break scripts; a whole bunch of stuff starts breaking once the disk fills though.
- TallGuyShort 13y ago
  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.
- mzs 13y ago
  I've seen a script that uses flock and rm, it would break.
hexasquid 13y ago
Ahhhhh this answered a question I had when I was about 7: why couldn't I undelete the first character?
grn 13y ago
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 https://github.com/grn/careless
ChuckMcM 13y ago
'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."
- snowwrestler 13y ago
  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.
IvyMike 13y ago
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 http://docstore.mik.ua/orelly/unix/upt/ch23_09.htm

conexions 13y ago

Did you read the article?

TallGuyShort 13y ago
... 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.
- conexions 13y ago
  Do you have an example of how aliasing could break a script?

alperakgun 13y ago

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

koenigdavidmj 13y ago
Simply replacing 'rm' with a no-op or error command (or removing it entirely) would break scripts. Trash can would not.
tankenmate 13y ago
You're right directly it wouldn't break scripts; a whole bunch of stuff starts breaking once the disk fills though.
TallGuyShort 13y ago
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.
mzs 13y ago
I've seen a script that uses flock and rm, it would break.

hexasquid 13y ago

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

grn 13y ago

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 https://github.com/grn/careless

ChuckMcM 13y ago

'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."

snowwrestler 13y ago
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.

IvyMike 13y ago

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 http://docstore.mik.ua/orelly/unix/upt/ch23_09.htm