>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)"