Messages in this thread | | | Date | Thu, 4 Mar 1999 07:42:11 -0500 (EST) | From | "Mike A. Harris" <> | Subject | Re: 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/
| |