>On Sun, 30 Jun 1996, Ian Main wrote:
>> I suppose I'm a bit late on this one but.. Wouldn't it be best to
>> implement undelete in user space using a new rm? One could write it so
>Yes ... but there are more ways to delete than just "rm". Lots of programs
>can delete. rm, cp, mv, redirection of output, any compiled program that
>contains code to open a file in write mode.
Whereas the number of system calls involved is limited:
unlink, rmdir (if want to track directories)
rename (may delete target)
open, truncate (open may truncate, maybe want to track truncations)
Go to a low enough level in the fs, and (if you want to track
deletions of files, rather than links-to-files) you only have one
routine involved, eg. ext2_free_inode (and maybe ext2_truncate).
The main thing a user-mode implementation _can't_ do is treat deleted
files as pseudo free-space - usable whenever the fs needs more space.
You can have a purge deamon or cron-job, but there is no way for the
fs code to call it when it runs out of space (except kerneld maybe).
Also your deleted files will still exist as "real" files, using real
quota I suspect (unless you modify quota - in the kernel...).
>Which brings another point: how widely interpreted would the "undelete"
>thing be? If I have a database program which modifies a file, should it be
[...]
I would go for any operation which removes the _whole_ file (rather
than modifies it) - that way deletion won't require extra space.
You could also trap file truncation - probably limiting this to the
truncate-to-length-0 case. Could be tricky to implement, and deletion
would use up another inode, but it would catch a few common mistakes,
particularly "foo > file" where you really meant "foo >> file" or
"foo > file2".
ray
--
Ray Auchterlounie Research Student (still) at:
<rda@kythera.demon.co.uk> Signal Processing Group
<rda@eng.cam.ac.uk> Cambridge University Engineering Dept.
"Don't ask me about my thesis (TM)"