Re: EXT2_UNRM_FL
Richard Gooch (rgooch@atnf.csiro.au)
Thu, 4 Mar 1999 16:22:17 +1100
g@cx888441-a.cv1.sdca.home.com writes:
>
>
> On Wed, 3 Mar 1999, Theodore Y. Ts'o wrote:
>
> > Date: Thu, 4 Mar 1999 10:26:46 +1100
> > From: Richard Gooch <rgooch@atnf.csiro.au>
> >
> > (d) why not do it in userspace anyway? I did that years ago, although
> > I "moved" files to /tmp, but it would be easy enough to move to a
> > garbage/$LOGNAME directory on the same FS.
> >
> > Absolutely, agreed. As I said earlier, there are plenty of user-space
> > "rm" replacements, and doing it in the kernel is almost certainly not
> > worth the pain.
> >
> > It might be worth it for the kernel to add a wakeup to the undelete
> > daemon telling it that space is low and it should remove some of the
> > deleted files, but I'd want to see how well a strategy of polling every
> > minute works (or doesn't work) before deciding whether the extra kernel
> > bloat was worth it.
> >
> one thing I am concerned is the those 'rm' replacements does not cover all
> the cases. For example, you can call 'unlink' directly from c/perl
> program, which will not go through 'rm'. If you really want undelete
> freature, I think it should be done a little higher level than, replacing
> 'rm'. hrmm that makes me wonder.. when you overwrite a file, does the
> kernel 'unlink' the file first and assign a new inode?
OK, so do it in the C library, or write a wrapper for unlink(3) and
use LD_PRELOAD and override that way. That just leaves old statically
linked binaries. I don't consider this feature to be sufficiently
critical such that old static binaries need it.
You can overwrite an existing file. The same inode is used.
Regards,
Richard....
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/