> > > (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.
If it's at all a security concern, then it's a pretty big concern. Anyone
can find a way of getting their own statically linked binaries. I don't
think doing it in the C library would be that great an idea... or that
useful an idea for that matter. Adding some conditional code
into vfs_unlink() in fs/namei.c would be great 'coz that's the multiplexer
for the various filesystems' unlink code. It'd also make it pretty easy
to turn off. You could even throw in a file into proc to turn it on and
off. That'd be the bomb -- I'd turn it before alcohol, turn it back off
when I'm sober :-) If I remembered, that is...
Maybe what could be done is have a .garbage directory as suggested above,
with a directory tree built that mirrors the rest of the filesystem. Any
deletion within that .garbage directory would be passed on to the actual
unlink() code (which would be irreversible, like the trashcan on a couple
notorious OS) -- any deletion outside that tree would be replaced with a
call to hard link to the new location in the .garbage tree, then the
unlink code would be called for the original file. The new hard link
could be named with the original filename with a number appended to it,
like vfs.c.1, vfs.c.2, so you could have multiple levels of undelete, in
case you deleted the file, and put a new file in place, realized your
error, deleted the file and... ack! Maybe that's going overboard. I
dunno.
I think the tree would have to be built as necessary, just flip through
the parent directories until one exists, than flip forward creating them.
Otherwise all the directory functions, etc, would have to be overridden to
generate the 'spectral forest' (I love that term). Also, you'd have to
prebuild that .garbage tree before booting with a kernel that had this
implemented, or stuff would blow up immediately.
I think someone mentioned having a kernel function that checked every
minute or so to check disk space and flush out old files if necessary.
That sounds pretty good too, but under the system I'm describing, that
would probably be better implemented in userspace. It could even be done
as a shell script, come to think of it.
It doesn't sound all that hard actually. Only one file to modify, and
it's a simple function. 95% of the code would be easily isolated into its
own function, so nobody need compile it if they don't want it.
--- Tani Hosokawa River Styx Internet
- 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/