Re: undeletion at filesystem level or in extra filesystem?

[Niels Möller]

Bryan Wagstaff <bryanw@xmission.com> writes:

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

My main concern is that the file update pattern open, write, close,
should be atomic when seen by other processes. I.e if some other
process opens the file for reading in the middle of the update, it
should see the previous version, independently of what the updating
process is doing.

Even if some other process opens the file for write in the middle of
the update, one should *not* end up with a random mix of the two
processes' ideas of what the new file contents should be. One of the
processes should win and make its internally consistent change to the
file, and the loser's changes should be discarded. Which of the two
that wins is less important.

Careful programs almost do this already already, by creating a
temporary file and then using the atomic link operation to replace the
old version, with the usually unwanted sideeffect that the old inode
metadata is lost. It would be nice (but un-unixish) to instead make
sure that the right thing happens by default.

So this is mostly orthogonal to versioning, even if these two feature
naturally can work together.

/Niels