> 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?
Mark it as undeleted. The inode will contain different time stamps
probably, and the inode will be different - so they are still unique.
> 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.
Yes.
> 2) What's the behaviour when deleting a file with multiple links.
unlink("blah") when blah has more than one reference isn't a delete.
ie. a delete is when the last reference is removed. Tracking hardlink
movement needn't be a kernel issue.
> 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.
No, dtime is only set when the last reference is nuked.
> 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
You can't. You cannot delete a non-emptry directory. If a directory
contains undeletable files, the directory cannot be removed.
> 4) Should directories be undeletable?
Directories could/should be treated like any other kind of file - so
yes. But, when restoring a directory, a sanity check needs to me made
to ensure everything it references exists or can be made to do so.
> 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.
Purging could be done in a variety of circumstances depending on what
the user decides is right for them.
I'm not 100% convinced any of this need kernel changes though, since
unlinking could be handled by a libc wrapper (I did something similar
by modifying libc some years back - it worked great).
And before someone says, not everything is dynamically linked, I'll
say that not everything has to remove files using unlink or rename,
some applications make zero the data or something first, so userspace
solution or otherwise, there will always be exceptions.
-Chris
-
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/