Just to put a slightly more practical spin on this thread, it's probably
worth spending some time on specifying the desired behaviour before
starting to work on implementation.
I can see several situations that has to be resolved/decided on before
starting implementation.
In the following I use undeletable to mean a file that's been deleted, but
can be recovered, and purging a file to mean remove the ability to
undelete the file, making its blocks and inode ready for reuse.
1) What's the behaviour when we delete a file with the same name as a
previously deleted file?
My suggestion here is to keep all of them, but remember to add the
ability to disinguish between them in the undelete utility, possibly by
deletion time.
2) What's the behaviour when deleting a file with multiple links.
This is where we have a problem with using deletion time, since this can
have multiple values depending on when the different links where
deleted, which mean it can't be kept in the inode.
Using name mangling in a .deleted dir, eg. <oldname>.<delete time> might
solve these two.
3) What's the behaviour when deleting a directory with undeletable files?
Should the files be moved to a common directory like it's done in the
fs used by Netware or
4) Should directories be undeletable?
5) What should be the behaviour of the thingie freeing up the space?
A minimum time before files can be purged? Tuneable?
General timeout of undeletable files, so they'll disappear after a while
whether the space is needed or not? Tuneable?
On demand purging, in my opinion a must.
Comments please.
-- Henrik Olsen, CNA, working on CNE. URL=http://www.iaeste.dk/~henrik/ Get the rest there.
- 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/