Undelete In Linux

Manuel Arriaga writes "[To the editors: I am not a professional programmer, nor will I ever be one. My income does not depend on my computing/programming skills, and hopefully it never will. So promoting free software I wrote does not help me in any financial way, no matter how indirect. libtrash is free software (GPL2), and I distribute it for free from my website. I have nothing to gain from the increased exposure, except for knowing that I am helping others. And I know slashdot isn't freshmeat... With that out of the way:] I have seen this topic discussed in the LKML multiple times by now, and many more people asking in the newsgroups why "I can't recover my deleted file on GNU/Linux". Here is my answer to that question. libtrash gives Linux a real "trash can". And it has been doing so (with varying degrees of stability) for more than one year now. If you consider it appropriate, make this information public on slashdot."

Comments

Re:I know you're kidding, but....

[oever]

[X] Easy support for video files and DVD - mplayer

I've installed mplayer on two SuSE 8.0 linux machines, and it's amazing. You can see DVD's, AVI's and even look at at microsoft media streams.
e.g. 'mplayer mms://streaming.omroepbrabant.nl/live1'

And how easy do you want it? You can easily make an icon on the desktop that starts mplayer on the dvd currently in the drive.

So, visit www.mplayerhq.hu and rejoice.

I'm Torn

[ReadParse]

I know in my heart that there's no need for this on Unix, because you shouldn't run as root AND use rm -rf and THE decide that you shouldn't have done that. There are safeguards in place and, after all, since you're a Linux superuser, you're either good enough that you don't make that kind of mistake or the system isn't important enough for it to really matter.

Having said that, even though I know how dumb it was, I once accidentally issued `rm -rf /bin`. Funny story, though:

For some reason or another, I happened into an additional hard disk that I put into my Linux box at work (not a production box). I don't remember how big it was, but it was big enough relative to my primary disk that, when I needed a mount point, I chose /big. That was the first mistake. I have no idea why I felt the need to mount it that close to the root. Although the similarity between "big" and "bin" is obvious in retrospect, it is, after all, retrospect.

Actually, that wasn't my first mistake. My first mistake was running as root.

I mounted the disk and played around with it. I suspect that it was my first time playing around with an additional hard disk, so I copied files over and examined "df -k" and so forth, and eventually I guess I decided to unmount it and do it all over again... I probably would have done endless, mindless file copies for the rest of the day, I was so thrilled with it. Hey, I was young.

This is where it gets embarassing. Perhaps everybody has some mysterious glitch which adds confusion where there should be none. Yes, I honestly do know the difference between a symlink and a mount... I swear it. But in the very brief period of time that it takes to type a command, I sometimes confuse the two in my mind and try to unmount using the "rm" command. More specifically, "rm -rf".

I also noticed on that day that we humans have kind of a built-in autocompletion. If you type the first few letters of your last name, you have a tendency to follow through with the rest of it. And that tendency increases dramatically the closer you get to the last letter. The way I noticed this was when I attempted to issue `rm -rf /big` and immediately pressed return (I found that return is also a mysterious part of that autocompletion).

Just so you know, there are a great many important things in /bin. Among them, all of the shells, chmod/chown, grep, kill, ls (try working without that), mv.... the list goes on and on.

This story also reminds me of the time I evaluated WS_FTP Server when it first came out. I needed an FTP server so I could go home and work on some files on an NT server. I wanted access to the whole box, so I set up my FTP account's home directory as c:\ -- I had no idea that when I deleted that account it would attempt to delete the user's home directory, even if it was c:\.

I've never heard a disk thrash like that before or since. And you've never seen anybody turn a box off as quickly as I did when I realized what was going on. Alas, it was too late. Reinstallation and backup restore (yes, I had a backup) commenced immediately. By the way, I've never fully accepted responsibility for that -- I still feel like it should have said "You're about to delete c:\ and all of it's subdirectories. Are you sure?" Because I really didn't think it would do that.

Anyway, my point is that "there, but for the grace of a godlike substance, go you". It's really easy to say we're too good for this, and there's a damn good case that a linux trashcan is not necessary, but for those who want it I think it's a cool piece of code.

That is all.

RP

safedelete

[oneeyedman]

After losing eight hours of editing work during a botched backup attempt, I heard about a utility called safedelete. I can't find much on it, but here it is from Ibiblio. Interestingly, the person that told me about this utility (which sets up a trash directory with timed expiration and a system of aliases for rm and related commands) was an old Unix hand, and only secondarily a Linux user. The program works fine in Debian, I can report.

And I don't get these people saying they are too smart to need an undelete capability. Must be nice!

The TCT

[schlach]

I can't believe no one's mentioned The Coroner's Toolkit. Written by Dan Farmer and Wietse Venema, those crazy kids that wrote SATAN, back in the day. It has all kinds of fun tools for poking around backstage on a *nix box, ostensibly forensics-related work after a machine compromise, but if you accidentally delete something important, you could pretend that someone else broke in and did it. =)

From the FAQ:

What the hell is it? The Coroner's Toolkit (TCT) is a collection of tools designed to assist in a forensic examination of a computer. It is primarily designed for Unix systems, but it can [do] some small amount of data collection & analysis from non-Unix disks/media.

Features: Notable TCT components are the grave-robber tool that captures information, the ils and mactime tools that display access patterns of files dead or alive, the unrm and lazarus tools that recover deleted files, and the findkey tool that recovers cryptographic keys from a running process or from files.

"Take this object, but beware! It carries a terrible curse!"

The advantage is has over some recovery options is that it's entirely post-mortem. If you just deleted the boss's laundry-list, you could go download it, build it, and stand a pretty decent chance of recovering your file.

The disadvantage is that, perhaps like a real autopsy, it's not for the faint of heart...

Why not do it for real?

[Salamander]

It shouldn't be all that hard to do this in-kernel, so it doesn't have library-preload dependencies or side effects and catches even stuff that comes into the kernel from unexpected directions. All you need is a dirt-simple filter driver that you push on top of the filesystem to change delete/unlink calls so they move stuff into the trashcan, plus some ioctls to view/empty it.

Oh, wait, Linux doesn't have filter drivers. For a moment there I forgot we were talking about a "technically superior" OS.