Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!bu.edu!att!rutgers!rochester!pt.cs.cmu.edu!gandalf.cs.cmu.edu!lindsay
From: lindsay@gandalf.cs.cmu.edu (Donald Lindsay)
Newsgroups: comp.arch
Subject: File Changes (was: Re: Sun bogosities, including MMU thrashing)
Message-ID: <11685@pt.cs.cmu.edu>
Date: 27 Jan 91 16:05:36 GMT
References: <1991Jan27.003821.24814@unx2.ucc.okstate.edu>
Followup-To: comp.os.misc
Organization: Carnegie Mellon Robotics Institute, School of CS
Lines: 25

<NOTE THE FOLLOWUP-TO>

In article <1991Jan27.003821.24814@unx2.ucc.okstate.edu> 
	minich@unx2.ucc.okstate.edu (Robert Minich) writes:
>With a log based editor, what happens if someone changes the file while
>you're editing it? Are the files locked while in use?

One answer is locks. Unix didn't offer that, so some editors (on exit)
check that the original's last-modification-date is still the same.

There is a _lot_ of OS literature arguing that files (except for data
bases) should be unmodifiable. When someone writes one, they are
always creating a new file. If an old file of the same name existed,
then the old and new files coexist, and are told apart by OS-
generated version numbers.

This has interesting media advantages - it meshes well with WORM
technology. It does some good things to distributed environments,
making things more atomic, more nameable. It's also convenient -
"undo" == "delete latest". Users get some policy control: TOPS-20
allowed a keep amount (e.g. 3) to be set per-directory, etc.  Our
backup tools automatically migrated old versions to tape. In short,
it was pretty well win-win.
-- 
Don		D.C.Lindsay .. temporarily at Carnegie Mellon Robotics