Is there any rm log with removed files?

Question

Is there any way to check what was recently removed with rm command?

Solution 1

Some different solutions

There is no log, but if you want...

Watch for deleted entries and log

You may use inotify libraries in recursive and monitor mode:

inotifywait -e delete --timefmt %c --format '%T %_e %w %f' -r -m / >/path/logfile
Setting up watches.  Beware: since -r was given, this may take a while!
Watches established.
Fri Jul 19 11:57:39 2013 DELETE /tmp/ testfiletodelete
Fri Jul 19 11:57:46 2013 DELETE /home/user/ testfiletodelete

This is a sysadmin approach: All user, all directories and mounted points...

Warning this could be a little overkill read carefully the man page and add some options like --exclude

Patch bash rm command

You could add something to your .bashrc...

Transform rm from delete to move to trash command

mkdir -p $HOME/.Trashcan
rm() {
    local destdir=$(mktemp -d $HOME/.Trashcan/trash-XXXXXXXXX);
    mkdir $destdir/files
    echo $0 $@ >$destdir/command
    set >$destdir/environ
    mv -t $destdir/files $@
} 

So every time you hit rm in your bash, files will be moved to a directory, command and environs will be saved too.

As each rm will create a new directory correctly dated, there is no need to use date.

Adding a log step to rm command.

But if you just wanna log your operation, at user lever:

rm() {
   date >>$HOME/.rm.log +"%a %d %b %Y %T: rm $@"
   /bin/rm $@
}

could do the job.

Nota 1

As @slhck rightly said: redefining usual commands may forge bad practice for new users, so if you modify such standards commands, your have to not forget this when you're working on another system!

Nota 2

This patch only rm command runned by interactive user shell. You may edit /etc/bashrc for making them for all users, but at all, only bash tools could be affected.

If files are removed by unlink in perl for sample, this will not be logged by this.

Or even if ksh, dash or else is invoked instead of bash... no logs.

Nota 3

For accessing original command, instead of alias or personal function, you have to precise full path: /bin/rm myfile will remove myfile but bypassing rm function, nothing will be logged.

Solution 2

If it is you who accidentally removed files, and your shell supports history, you can list the history back like this:

history | grep rm

Of course, you'll need to do an insight search through the history to know where you deleted the file.

If it was another user, maybe his/her ~/.bash_history or similar file (for whichever shell the user uses) may have that information, if they didn't delete it from there.

But actually, as other answers propose, there's no log. Just means of scanning the surface for removed files not-yet-overwritten.

By the way, using a Copy-on-write filesystem, such as ZFS or btrfs, you can track deleted files between "states" of the drive in time, called snapshots.

You can have a cron task run with the required time granularity to ensure there is a recent enough snapshot, and then diff between the snapshot and the current state.

There's another way. You can compile your own rm binary, which does save traces of what did it do.

Comments

[F. Hauri]

Sorry, no. You may use harddisk recovering tools, if needed, but there are no logs.

[F. Hauri]

@ssice Right, I've added another version of same principe.

[slhck]

Redefining builtins like rm is bad practice, because you'll get used to being safe when you're actually not—imagine working on another system that doesn't have this function. It's better to learn from those mistakes and type rm -i or similar whenever unsure, or list the files before deletion and then replace ls with rm.

[F. Hauri]

@slhck ( alias ls=rm ? ... ;-) Well, you're right, I agree: This not real good idea could have lather border effects... But this could help first steps of novice, mostly if this was added by himself. For myself, I use alias ls="/bin/ls -ltrF --color --show-control-chars" la="ls -a" and be never surprised when ls command don't give usual effect.

[patryk.beza]

I think that there is no point in reinventing the wheel. See: safe-rm package (read more: serverfault.com, launchpad.net, Debian package).