Re: undeletion at filesystem level or in extra filesystem?

[Bryan Wagstaff]

-------------------
>nisse@lysator.liu.se (Niels Möller) writes:
>
>> By the way, do you think there's any chance to change the semantics
of
>> open and write? I'd like the default behaviour to be as follows:
>
>But basically, yeah, if someone opens for O_WRONLY, writes, and
>closes, it would be nice if the old contents were cleanly saved as a
>"version".
>

That could get really nasty when it comes to large files that are
opened/closed frequently.  It also seems to open the door to some
security problems.

It wouldn't take long for a 10MB log file to take up an entire disk
with new versions.  Also, what about frequently used directories and
their inodes?  How about files/directories when affected by various
translators?  What would happen with compressed files being translated
as directories?  What if I change one byte in a multi-gigabyte file
with automatic versioning?  How would versions affect quotas: could I
create a malicious program that peforms open/edit/close on a small
file and consume the entire disk?

Automagic file versioning should probably be in the domain of
applications, not the filesystem.  If the filesystem were to support
anything, it would be creating a list of inodes to use in each file,
sort of like copy-on-write memory, instead using a copy-on-write
inodes.  But that gets back to the original problem of undelete.

The VAX VMS I used as a student had automatic file versioning, and I
found that I was constantly erasing versions to keep below my quota. 
That kind of versioning didn't do much for undelete; When I accidently
deleted my work, I tended to delete with * rather than a specific
version number.  So I think that file versioning and undelete should
be considered separate issues, and I agree with others in the group
that undelete belongs outside the filesystem.

Okay, my two cents are in.

Bryan Wagstaff.
bryanw@xmission.com