> Date: Wed, 3 Mar 1999 16:01:12 -0500 (EST)
> From: Alexander Viro <viro@math.psu.edu>
>
> It's fairly easy to implement, though. One line in
> fs/namei.c::may_delete(), one line in fs/nfsd/vfs.c::nfsd_link(), pair of
> #define's in fs.h and one more line in fs/ext2/inode.c::ext2_read_inode().
> If somebody wants it I will include it into the next portion of VFS
> cleanup that will be submitted to Linus - it obviously doesn't affect
> anything else. Final decision belongs to Linus, indeed, but I think that
> it's worth doing.
>
> How were you planning on implementing it? It's not too hard to
> translate a unlink to a rename call, and move the file to some
> directory; but handling (a) undeleting the inode, (b) security so that
> users can't see other people's deleted files, and (c) automatically
> deleting "deleted" files when the filesystem needs space, all starts
> making the problem a lot harder....
<looking at ext2_fs.h>
Sorry, I've misparsed it ;-< What I was thinking of is
NO_UNLINK stuff - behaves as APPEND_ONLY and IMMUTABLE wrt link
creation/removing and gives no protection to the contents of file.
It is useful in many situations and it *is* easy to implement.
But yes, UNRM is different... Actually I'ld propose to take one more bit
of attributes for that. UFS has such thing (ignored in Linux) and VFS
support for that would be very easy to add (I already did VFS part and
changes to UFS driver). Could you comment on that? All I need on ext2 side
is a spare bit in ext2_i.i_flags (user-visible).
-
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/