lkml.org 
[lkml]   [1999]   [Mar]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: EXT2_UNRM_FL
    On Thu, 4 Mar 1999, Richard Gooch wrote:

    > > > (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/

    \
     
     \ /
      Last update: 2005-03-22 13:50    [W:6.519 / U:0.156 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site