ext3 undelete shell script
 

This is a project that is a little over my head, so I wanted to explain it and see if my idea is even plausible.

The Problem:
I have been using Linux so much lately that I don't think I'll ever go back to Windows. I have used Linux on and off for years, but this time it's sticking to me. So Saturday morning I started converting some of my FAT32 partitions to ext3. Two of them to be exact: /dev/sdb2 and /dev/sda2. I copied all my filed from /dev/sdb2 over to /dev/sda2. I formatted /dev/sdb2 and proceeded to copy all the files from /dev/sda2 on it. Then I formatted /dev/sda2, and I needed to set its mount point to /home. I logged into root and ran rm -rf under that path. It was the right thing to do since all my documents were already backed up on /dev/sdb2; what I forgot was to umount /dev/sbd2 before removal and it happens to be mounted under /home/USER/incoming. I deleted my backup on accident.

My Idea for a Solution
Since it was freshly formatted ext3 and all files written to it an hour earlier, they should all be inline without fragmentation. I was reading online that to undelete, you should grep for file contents. I was thinking it may be easier to grep for the hex character 1A which should notate EOF. That would serve as a marker to separate each file. Then I could grep the start of the data to find its declared mime type and give it a name using an auto-incremental number. I'm rather certain I could do it with a C program, but it sounds like it could happen with just a shell script. Then again, I could be way off and it couldn't happen either way.

Anyone interested in helping, your feedback and assistance is appreciated. After this, I'm tempted to tweak my umask on the nested partitions in /etc/fstab to limit root's access... only delete my personal files as my user, umount as root ;)

-Joshua

Instead of reinventing the wheel search for photorec and foremost (and threads on LQ about situations in which you want to carve data).

I searched for threads on ext3 undelete methods and found no good methods. I had never heard of photorec nor foremost, and they didn't come up in my previous searches. Now that I know what to look for, I see this as an easier process. I still want to get into some kind of programming project, just seems like there's nothing to do other than re-inventing the wheel. The important part is that I have means for recovering files on ext3 now, thanks.

-Joshua

Mind you, there's nothing wrong with re-inventing the wheel. Some even make money out of it. Then there's OSS like TCT, Sleuthkit, PyFLAG, Foremost, Photorec and such. If you want a project and you feel capable of taking on stuff I would strongly suggest *joining* any forementioned OSS project since they could all use help. If you like to do one yourself then for it to be going somewhere I could suggest reading up on filesystems first, move on to "basic undeleting" and then to carving. There's lotsa useful forensics docs out there, and a lot of them are sourced through web logs.

backup script
 

#!/bin/sh
# Written by Vincent Chapman 2008
# -- Do the Following commands to set this backup up --
#
#sudo bash
#cd /bin
#mv rm rm-files
#mkdir /usr/share/deletedfiles
#chmod a+w /usr/share/deletedfiles
#cp [thisfile] /bin/rm
#chmod a+rx /bin/rm
#
# Ok now our backup script
#
# Screw EXT3 and zeroing the pointers, lets make a backup first
if [ "$1" != "" ]; then
if [ "$2" != "" ]; then
cp $2 /usr/share/deletedfiles
rm-files $1 $2
else
cp $1 /usr/share/deletedfiles
rm-files $1
fi
else
rm-files
fi
exit 0

I wouldn't want to replace rm. I could however make a one-line alias that does the same thing. (Per user, instead of systemwide).

alias r='mv $1 -t /usr/share/deletedfiles'

Now you could enter r <file1> <file2> <fileN>, and it would be moved to /usr/share/deletedfiles. You can actually override the normal rm command with this alias, by changing from alias r=... to alias rm=... (Then to remove files you would have to /bin/rm <file1>..., mv <file1> /dev/null or make a new alias to really delete files. Either way, it would be _really_ annoying IMHO).

eligant solution
 

The free software foundation website (coreutils) has the following suggestion posted in the message boards for bugs. I added the rmdir alias myself.

alias rm="mv --force --target-directory=$HOME/.Trash/"
alias rmdir="mv --force --target-directory=$HOME/.Trash/"

Removed files go into GNOME trash, the icon show papers in the trash even. You can click on the trash icon anytime you want to delete or undelete a file or directory.

I installed the alias in ~/.bashrc for each user, except /root, where I specified --target-directory=/home/myaccount/.Trash/ as root should never login into GNOME.

Using move-to-thrashcan aliases doesn't cover applications removing files and shouldn't be relied on (same for the standard 'rm -i' alias in some distro's). There's libtrash(?) though which intercepts syscalls through LD_PRELOAD. If you want to have something really awesome check out Ext3cow.

EXT3COW is cool, I'll have to look at it more.

What started this of course was human error, I put 6 hours of programming into my BBS source code and at 3am when I was getting ready to make a tar ball backup I typed rm * instead of rm *~ and that was it. Now I got lucky and scites still had the source code opened on the desktop so all I had to do was re-install from last backup and resave the program out. But the RM alias to MV would have been nice about then. I understand you can't undelete if deleted by a program, but at least those aliases would atleast bring bash and gnome into the same trash system. I am going to change my source code in the BBS to do the same thing. This is a make aware issue for programmers. I never considered it before, but then, never was unable to undelete before.

Why not use libtrash instead of the alias? From the README: "libtrash works with any GNU/Linux program, both at the console and under XFree86, and operates independently of the programming language the program was written in. The only exception are statically linked programs, which you probably won't find. It can be extensively configured by each user through a personal, user-specific configuration file." Seems a lot less work to me.