lkml.org 
[lkml]   [1996]   [Jun]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: Drawbacks of implementing undelete entirely in user space
Date
From
Hasdi R Hashim wrote:
>
> On Fri, 21 Jun 1996, Luca Lizzeri wrote:
> > I am sure there are plenty of clever solutions which can be implemented
> > with minimal overhead in the ext2 filesystem, (maybe making it
> > configurable: CONFIG_EXT2_UNDELETE) and a suite of user programs for the
> > management of deleted but not purged files.
>
> 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

A kernel ext2fs undelete option would unlink the file, and relink
it into something like a lost+found directory at the root of that
filesystem. Just before running out of blocks on that filesystem
would you start looking for the oldest file there, and really
unlink it. (would have the added benfit that you don't need to wait
for 20 seconds when you delete a large file....)
I've schetched the userspace solution already. I'm getting mad at
these discussions where more time is spent discussing why and how
to do it while it could've been implemented yesterday if we'd do
something instead of talk about it.

I'm working on "splitting the superuser rights to bits" (i.e.
vga console programs need access to ioports, NOT unlimited access
to the filesystem).

This weekend:
Saturday: Superuser split.
Sunday morning: Undelete in userlevel.
Sunday afternoon: Undelete in kernel.

Anybody want to gather some betatesters?

Roger.



\
 
 \ /
  Last update: 2005-03-22 13:37    [from the cache]
©2003-2011 Jasper Spaans