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