

Should We Abolish User Access to rm? (2011) - giis
http://www.linux-mag.com/id/7950/

======
TallGuyShort
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.

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

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

------
nine_k
Why, decapitation definitely rids one of headaches, but why not consider less
invasive options beforehand?

A file system might implement `rm` so that it does not lose data outright, but
keeps a few recently deleted files intact for undeletion. I suppose every
journaling FS already includes everything necessary for it. E.g.
[http://extundelete.sourceforge.net/](http://extundelete.sourceforge.net/)
uses ext3/ext4 journals. AFAICT NTFS undelete works the same way.

Some file systems have explicit snapshots and other tools that facilitate
rolling back changes: xfs, ext3, ext4 all support snapshotting on Linux when
run under LVM. It's even better than undelete.

~~~
keenerd
> I suppose every journaling FS already includes everything necessary for it.

Depends. Ext seems to use a F̶I̶F̶O̶ LIFO for the empty block list. It can
make recovering data more tricky.

Last time I tried to recover some deleted data, it was about an hour after the
delete took place. The recently deleted blocks were the first over-written by
normal background tasks and everything I wanted to save was gone.

Every file more than a few hours old was easily recovered, right back to
projects I had deleted a year previously.

edit: Thanks.

~~~
colanderman
I think you mean LIFO? A FIFO would imply that your old projects (first in)
would be re-used soonest (first out).

------
SiVal
If you alias rm for some users, you'll train them to think that rm has an
undelete feature: bad idea.

Experienced *nix users often work from an ordinary user account and turn to
"sudo" only for special cases so they don't accidentally mess things up. When
you use "sudo", you know you have to slow down and be careful. So why isn't an
undoable file delete function not the default file deletion command, with rm
reserved for special cases where you slow down and make extra sure you really
want an irreversible delete?

Automated scripts would use rm as always, but for interactive work, especially
on client machines with giant disks such as the typical general purpose user
computer these days, there should be a different standard command for deletion
that everyone learns long before they learn about rm.

------
verbatim
Leaving aside technical arguments against doing this, I don't think it would
solve the problem anyway. Users would inevitably decide that they want a real
"remove" operation (because yours is now wasting their disk space, etc.), and
teach themselves to call their new fancy "really_rm" alias. And then just
accidentally delete files with that instead of "rm".

(Anyone ever gotten too used to shift-Delete in Windows? Yeah...)

Instead, automate backups or file system snapshots.

~~~
takluyver
Yes, in both Linux and Windows, I've got used to hitting shift-delete, return,
when I want to delete a file. And yes, at times I've done that only to
immediately realise I'd got the wrong file.

I think GMail has this right: instead of a confirmation, it does what you
asked for, and has an obvious non-modal undo button. Also, because I know
things in the trash will be discarded after 30 days, I don't feel any pressure
to 'really delete' them myself.

------
deepblueq
Is this really that common an issue? It seems like anyone who's at a level
where they're using rm regularly should know that that's a command you think
before issuing. If they didn't, then that's exactly why you have backups.

Then, if it was in the backups, the short-term problem is solved, and maybe
the experience will scare them into being a bit more careful in the future.

If it wasn't in the backups, the most likely reason would seem to me be that
it was created since the last backup (not that I'd know, IANA sysadmin), in
which case there wasn't a ridiculous amount of work lost - maybe the
experience will make them a bit more careful in the future.

Of course, the above doesn't apply with the sort of user who thinks IT is
magic and can do anything, but if they're using rm, you've got bigger
problems.

Also, personal opinion, but I hate automatic trash folders - rm is supposed to
delete stuff. If I want a recycle bin, I'm happy to mv to a folder I created
for the purpose.

------
dkrich
I like the solution but I am actually opposed to an out-of-the-box solution.
The reason is that precisely what makes Unix such a stable, fast OS is its
minimalism. It trusts the user to know what he/she is doing. Once you cross
over into taking into account user error you start to add bloat. I've seen
this happen recently in Rails 4.

Well-intentioned developers add a bit here and tad there and pretty soon you
have 400% of what you need to perform your daily tasks to protect yourself
from 0.001% occurrences. Which is actually ironic because I remember DHH
stating that he was vehemently opposed to type-casting. Anyway, I think it is
best to leave it up to end-users to build their own solutions and plug-ins for
desired functionality but to leave these types of catch-all's out of the core
product.

~~~
Someone
I somewhat agree with what you say, but: _" to leave it up to end-users to
build their own solutions"_? Is that optimism, naïvety, or am I overlooking a
dose of sarcasm?

~~~
dkrich
Ha, well not sarcasm. I guess I assume that if you are working in Unix you
know enough (or can learn) to create a script to handle this for you. Of
course that doesn't prevent somebody from running rm, but it does at least put
the brunt of the blame on the person who used rm anyway, despite the admins
advising against it in favor of the archiving script.

I guess the basic question is- should users be entrusted to permanently delete
anything? rm is probably my third or fourth most-used commands because it is
so fast and easy. It does exactly what it should- get rid of shit you don't
need anymore, and very quickly. For example, I use templates to generate web
applications and when I test new templates I will frequently want to get rid
of the auto-generated one I just created. Without rm this would be an
incredible pain in the ass or at least take more time and storage than it
should. I like keeping the core strictly utilitarian and leaving the layers of
safety to be built by bureaucracies after it has shipped.

------
drcube
How about we just don't backup anything? That's the user's job, and if they
didn't do it, they know their data is 100% gone, no backsies, when they delete
it. So maybe they'll be more careful. Backups are a moral hazard.

But seriously, I don't see an issue here. There are backups for a reason. If
it takes too much time to go through the bureaucracy of requesting backed up
data, that sounds like the problem that needs to be fixed, not the existence
of the "rm" command. And if the delay is there on purpose, it sounds like
everything is going according to plan. What's the problem?

~~~
ramy_d
What about the argument about loosing things between backups? Also, my
understanding what that this issue is about using administrator time, not
bureaucratic time.

------
jjindev
I was just thinking back to the 80's, when newspapers actually printed stories
about "rm" and "ls" and unfriendly computers. This was as the GUI came in and
cryptic commands were eschewed.

It took us a long time to accept the best of all possible worlds, GUIs more
most people, and genuine, expressive shells, for a few.

For those few, rm is not a problem, no. In fact, it's a reminder that this
isn't Kansas anymore.

------
ThatGeoGuy
One thing the article mentions is to alias rm, but they never mention just
performing a chmod to change the user/group permissions on the actual command
itself. I can't see why it's impossible to change the permissions on the real
rm command, while providing an alternate (or aliased, whatever you prefer)
command to move "deleted" files into the Trash/Recycle Bin/What have you.

You can later implement another in company program to perform the actual
deletion, with strict warnings, which can execute the real rm command with the
appropriate group permissions. Ideally, this should at least deter users from
blanket deletion of their file systems, though eventually some will come to
abuse the true deletion program, believing they know better than IT. However,
this is largely inevitable, and some users will always behave that way, so you
need to consider this when discussing any technical measures taken towards
something like rm.

------
mindslight
Yes. It should be replaced with wipe(1) instead.

------
cschmidt
I do remember a case on a mail list that shall go unnamed, where an
"experienced" member of the list sarcastically told a newbie that typing "rm
-rf /" would "solve her problem". Unfortunately, she dutifully tried it and
wondered why her machine wasn't working any more. There was quite a shitstorm
on the list after that. The smartass did feel very bad afterward.

