RECOVER EXT3 - Bootstraping the miniproject

Hi,
And now its time for our miniproject. We have decided to have the mini-project with the team , me,midhun,and vijin and vyshakh as usual. As for ever it was really difficult to make decision over what should be the project. Somehow we got the idea of a file recovery tool, and we saw that there is not so much such tools for the ext3 filesystem. Thus another story begins here 'The mini project days'.

We googled for the available documentations over the file recovery in ext3. There were not so docs in bulk, but the available once where capable of keeping the idea alive. We went through the documents of 'ext3grep' and some other saying 'file system forensic' neither of the documents said its easy to recover the lost files but they did say there is chances that the files can be recovered using the details in journal.

As we gone through a number of different documents, almost al of them were discribing the recovery method in some what similar way. All of them were using the tools TSK, foremost etc. Although there is no point in discribing the procedure in those articles here, they do come in the scope of the post. Lets have a higher level look over the structure of the inode of a file and how these articles recover the lost data.
The inode in the ext3 file-system
An image of the disk is created ( from where the file was deleted..).
The inode corresponding to the deleted file has been found.(The tool debugfs can be used for this)
The block group of the inode is obtained from 'imap' in debugfs.
The journal of the file is searched to get the entries for the particular inode in the blockgroup.
The journalled inode data is fetched and if it is of some size near our deleted file, the file is recovered using the tools like 'foremost'.

Here the major threat we faced is that using these tools recovery of a file which has its data present in the single, double and triple indirect pointers is not so easy. There is another problem that it can recover the files with extensions which are defined in the foremost only. Enhancing the foremost for the unavailable extensions is also didn't sound so good to us. As of now we had been on our way to find some simple but robust method that can better recover the file irrespective of the file size.

Then we thought if there was an option to undo the permanent deletion till its not over written then it would have been fine. That means if we are able to make the OS believe that file had not yet been deleted then it would have been easy to tackle this undeletion. Yeah here comes our idea behind the miniproject wich is robust and sound. Re-establishing the previous contents of the inode to itself will do the undeletion till the data is not overwritten. There is tools which will help to get the journal details to recover the datas in an inode at a previous time also to edit the inode, and these tools can be used to start the project and later these can be replaced with our own dedicated code.
And thus here is a turning point.......