Path: utzoo!attcan!uunet!cs.utexas.edu!sun-barr!apple!rutgers!tut.cis.ohio-state.edu!att!chinet!les
From: les@chinet.chi.il.us (Leslie Mikesell)
Newsgroups: comp.unix.wizards
Subject: Re: What kinds of things would you want in the GNU OS?
Message-ID: <8609@chinet.chi.il.us>
Date: 1 Jun 89 22:50:09 GMT
References: <106326@sun.Eng.Sun.COM> <4315@ficc.uu.net> <338@arc.UUCP> <8587@chinet.chi.il.us> <4357@ficc.uu.net>
Reply-To: les@chinet.chi.il.us (Leslie Mikesell)
Organization: Chinet - Public Access Unix
Lines: 32

In article <4357@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes:

>> Besides the obvious intent of the name, there is the advantage for
>> database usage that some directory operations are atomic.  That is,
>> you will normally never be able to access a filename in an inconsistent
>> state.  You cannot say the same for the contents of the files unless
>> explicit locking is done.

>I've been thinking about this statement, but it still does not make any sense.
>If you do a read or write that does not span block boundaries it should be
>atomic. So a binary read or write that's a power of two bytes in length should
>have no problem. Certainly I don't think I've ever seen a problem with utmp.

I was thinking in terms of the standard unix tools which typically create
a new file or truncate an existing one and write new contents. Thus a certain
part of the time the name exists but the content is not completed even with
only one writing process -- you don't even want to think about multiple
writers with the standard tools.  The only reasonable approach is to either
use a daemon process to schedule all writing or roll your own locking
procedure.  Under SysV you can make /etc/link executable by everyone (or
write the corresponding program yourself) and have something that is
an atomic operation to work from in shell scripts.  The more obvious
choice "ln" actually deletes the target before attempting the link(!).

BTW, what would a "power of two" bytes have to do with anything?  If
your write()s happen to be alligned within blocks you might not get
the final output mixed up, but there is still no guarantee that a
reader who may be reading the whole file will see what any (even a
single) writer thinks it is putting there.  That is, the reader may
read faster than the writer writes.

Les Mikesell