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:

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

And what if someone deletes using mc, or some other filemanager,
or their own code? It isn't transparent. I'd rather see it in
the filesystem myself.


--
Mike A. Harris Linux advocate GNU advocate
Computer Consultant Open Source advocate

The DVORAK keyboard layout RULES! I memorized it in 45 minutes
and I don't think I'm ever going back to QWERTY!


-
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.113 / U:0.516 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site