Messages in this thread |  | | Date | Mon, 24 Jun 1996 18:49:30 +0100 | Subject | Re: Drawbacks of implementing undelete entirely in user space | From | Ray Auchterlounie <> |
| |
In article <Pine.SOL.3.91.960622061500.12357E-100000@aluminum.engin.umich.edu> Hasdi R Hashim <hasdi@engin.umich.edu> wrote:
>On Fri, 21 Jun 1996, Luca Lizzeri wrote: >> I am sure there are plenty of clever solutions which can be implemented >> with minimal overhead in the ext2 filesystem, (maybe making it >> configurable: CONFIG_EXT2_UNDELETE) and a suite of user programs for the >> management of deleted but not purged files.
>Oookay... Just enlighten me: how would a kernelspace-level solution be >better than userspace-level solution?
I think that a solution in the filesystem (which is not necessarily in the kernel) will avoid a lot of problems a higher level solution would hit: Purging deleted files - a user level solution requires some sort of daemon to regularly check free blocks/inodes (on every filesystem) and start purging files if either falls below a set limit. You now have to trade "chance of filling up filesystem" off against "maximizing storage of deleted files". Better hope that daemon doesn't crash. At filesystem level - no problem, need a block or inode, purge a file, you automatically store the maximum number of deleted files possible.
Deleting across filesystems - a user level solution will have to check which filesystem the file to be deleted, and the wastbasket, are on - if different do we copy the file (could be interesting if you remove a lot of files over nfs over a slow link). If we always delete to a trash directory on the filesystem we need to check permissions and consider the security implications. At filesystem level this is no problem - we already know which fs the file is on and we keep it there.
Quotas - if deleted files count towards user quota then the facility will be of very limited use to users near their limits, even if disk space is available. If not then the quota implementation will need modifying. At filesystem level, deleted files would not be visible to quota - but they effectively take no space so quota is not needed.
File attributes - at filesystem level we can add file attributes like ext2fs "undelete" and "secure delete", undelete can then be specified per-file, per-directory, per-filesystem (mount options ?) and checks are trivial. From a higher level you need to be aware of all such attributes on all filesystems and you need to check them. eg if the user has marked a file for secure deletion then rm should delete it properly - but if you trap rm or unlink() and the filesystem gets told to just move the file instead...
I can probably think of more - the point is that all these problems don't arise in a filesystem level implementation. They could maybe be solved at a higher level - but only at the cost of much complexity and multiple system calls instead of just one.
[...] > Mac (or maybe Windows 95), use another approach to this. If you [...]
In both cases I think you'll find it's done in the filesystem - try it on a network filesystem (eg. Netware), I think you'll find the files are not recoverable from trash, they may be recoverable in other ways if the _server_ provides a mechanism for this.
> So, to undelete a file in DOS-like fashion, my suggestion is have >a setuid root program that... > 1. Unmounts the partition (or lock it) [...]
First killing off all processes using that fs, logging off users etc. Unacceptable on a multi-user system, not much use on single-user. If you want DOS undelete then use umsdos or msdos fs and reboot to DOS when you want to recover a file.
I'd rather have something in the fs - take a look at Netware for a good example.
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)"
|  |