Re: undeletion at filesystem level or in extra filesystem?

[Thomas Bushnell, BSG]

Bryan Wagstaff <bryanw@xmission.com> writes:

> >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.

"cleanly saved" might well include saving only differences.  

> It wouldn't take long for a 10MB log file to take up an entire disk
> with new versions.  

I should have specified opening O_WRONLY|O_CREAT|O_TRUNC; this is the
normal modes for "writing a file", and is very different from
appending to logs.

> Also, what about frequently used directories and
> their inodes?  

You can't open a directory O_WRONLY.

> How about files/directories when affected by various
> translators?  What would happen with compressed files being translated
> as directories?  

Translators are a separate issue, but the answer would fall naturally
out of whether "cleanly saved" involves sharing an inode somehow or
not. 

> What if I change one byte in a multi-gigabyte file
> with automatic versioning?  

Then one could save only the small change.

> 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?

A malicious program could just write a big file.  

> 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.

You seem to be saying "there are lots of complicated questions here".
I agree, and I think we need clear correct answers before we start
trying versioning or undelete.  

Thomas