Bryan Wagstaff <[EMAIL PROTECTED]> writes: > >[EMAIL PROTECTED] (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 _______________________________________________ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
