Protection For rm

Question

I sometimes work with my server over ssh. I don't want to lose anything because of an accidental rm. Is there a way of creating a trashbin for my server? I know it sounds stupid, but I just want to know whether there's a way of recovering stuff if I accidentally delete files.

I thought about adding a new alias for rm, but this won't always work. I sometimes use SFTP package of Sublime, and I also can accidentally delete stuff using it.

What can I do?

Thank you very much in advance.

Answer 1

If you add an alias to ~./bashrc you can prevent deleting of files. You can alias the command from the answer from Timothy Duane with

alias rm='trash-put'

Alternative:

alias rm='mv --verbose -f --backup=numbered --target-directory ~/.Trash/'

will mv files to your local Trash and also create backups if there is already a file with the same name.

If you want the alias globally: add it to /etc/bashrc.

Answer 2

First of all, you don't want to change the behavior of rm globally. That will simply break your system¹. Many programs call rm internally so if you change how that behaves they wont' work and this can have unexpected consequences. You will have to limit yourself to protecting yourself from rm.

You can, however, add an alias to rm, changing its behavior, to your ~/.bashrc. For ssh sessions, you would normally need to add it to your .profile instead but the default Ubuntu .profile calls .bashrc so that son't be necessary unless you've changed it yourself. Basically, if you don't know what I'm talking about, just use ~/.bashrc. The delete command in an FTP session is something completely different and will not be affected.

So, that said, here are a few aliases you could use:

1. rm -i and rm -I

   As explained in man rm, these two flags protect you from inadvertently deleting files. You can use either, depending on the level of annoyance protection you want:

   -i     prompt before every removal
   
   -I     prompt once before removing  more  than  three  files,  or  when
          removing  recursively.  Less intrusive than -i, while still giv‐
          ing protection against most mistakes
   

   So, for example, to have rm prompt you before each deletion, add this line to ~/.bashrc and ~/.profile`:

   alias rm='rm -i'
   

2. Install something like trash-cli as already suggested and then make rm an alias to it:

   alias rm='trash-put'
   

   Now, any files you delete with rm will be placed in ~/.local/share/Trash/files/.

3. Use the do-it-yourself approach with mv as suggested by @Rinzwind.

---

¹ Depending on how exactly you change its behavior, it might be fine, but it might break.

Answer 3

trash-cli might suit your needs

sudo apt-get install trash-cli

http://www.webupd8.org/2010/02/make-rm-move-files-to-trash-instead-of.html

Edit:

You could also make a backup of rm and then replace all occurrences of rm with a script

#!/usr/bin/python3
from sys import argv
from subprocess import Popen
args = ''
for arg in argv[1:]:
    args += arg + ' '
Popen('trash '+args, shell=True)

and then use

chmod +x rm

Although I have no idea how safe this really is.

Answer 4

All the proposed answered will work for your command line experience. But let me chime in with my personal suggestion: do not do that. Never.

Rationale: you should know what are you doing; using rm thinking that there is a safety net (with an alias, a global change in the executable(1), other things) will make you grow confident and you will make big mistakes when the safety net for whatever reason is not present --- that can be an update, another system, or whatever.

The rm command is a (complex) shell around the unlink() family of system calls --- see it as the linux kernel service that disposes of files(2). Many programs will just use the system call, completely bypassing your safety nets.

For example, the command

find . -name test2.aux -delete 

will directly call unlink, as you can see by using strace on it:

strace find . -name test2.aux -delete 
...
unlinkat(AT_FDCWD, "test2.aux", 0)      = 0
...

...and I bet the SFTP server will do the same. These are out of scope to the "protection" of your alias or even the rm binary substitution.

Even a simple mv, cp, or > file can destroy a file outside your safety net.

The only safe is a good backup(3). Learn to do it often, and double check all your commands. Triple if running as root.

---

Footnotes:

(1) don't do that, unless the replacement command is ready to accept exactly all the flags and corner conditions that rm manage.

(2) much more complex than that, really.

(3) or doing that at kernel level, probably by using a filesystem that has some kind of long term memory (a versioning filesystem). I remember working with VMS in the late '80s --- the filesystem did remember all version of a file appending a ";1", ";2" etc at the name, at kernel level. Handy but a maintenance nightmare.