Oookay... Just enlighten me: how would a kernelspace-level solution be
better than userspace-level solution?
Remember the undelete command in DOS? It was a hack. Undelete
feature was never thought of when DOS/FAT was designed. It was there by
accident. You see, when you delete a file in DOS, you are not deleting as
in deleting, but as in 'deleting'. :) That is, you are just MARKING them
for deletion; the first character of the file is overrwritten with a
special character (Now you know why UNDELETE ask you for the first
character?). The link to the chain of clusters (or blocks for you UNIX
geeks:) is still pointed by the file entry marked deleted.
Why was it done this way? It is a fairly quick way to delete a
file, and you don't have to modify the allocation table every time you
delete. If DOS needs more clusters, it runs through the directory for
entries marked deleted, and use the deleted chains.
Mac (or maybe Windows 95), use another approach to this. If you
want to delete a file, you *mark* them as deleted by moving to a special
pseudo directory. Once you are satisfied with list of files you want to
delete, you *purge* them, in Mac, by selecting Empty Trash.
So, to undelete a file in DOS-like fashion, my suggestion is have
a setuid root program that...
1. Unmounts the partition (or lock it)
2. Search the partition for unused inode entries
3. Check if the inode entries are the files you are looking
for.
4. Recover the file if the chain of blocks are still intact
5. Mount back the partition (or unlock it)
I am not really sure if some of the steps are applicable to ext2,
there are probably some limits to this. That's okay, because there are
limitations on what you can undelete in DOS too. Once Linus gets back, I
would like know HOW he undelete his stuff when he accidently removed his
filesystem. (I heard he did this by hand, I am wondering if this can be
automated:)
The Mac-style is left for the exercise of the reader. :)
Regards
Hasdi