lkml.org 
[lkml]   [1999]   [Mar]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: EXT2_UNRM_FL
Theodore Y. Ts'o writes:
> 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....

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

My rm replacement even purged the oldest files if the rubbish bin area
was too full.

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/

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