Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!ll-xn!cit-vax!amdahl!rtech!jas
From: jas@rtech.UUCP (Jim Shankland)
Newsgroups: comp.bugs.4bsd,comp.unix.wizards
Subject: Re: concurrent write(2) calls write bad data to file
Message-ID: <710@rtech.UUCP>
Date: Wed, 18-Mar-87 13:16:04 EST
Article-I.D.: rtech.710
Posted: Wed Mar 18 13:16:04 1987
Date-Received: Sat, 21-Mar-87 02:34:46 EST
References: <692@rtech.UUCP> <14589@sun.uucp> <7778@utzoo.UUCP>
Reply-To: jas@rtech.UUCP (Jim Shankland)
Organization: Relational Technology, Alameda CA
Lines: 26
Xref: mnetor comp.bugs.4bsd:236 comp.unix.wizards:1523

Well, fresh mail made me want to dig at this again.

Guy Harris writes:
> I don't see any obvious reason why this *couldn't* happen on any
> UNIX system that didn't lock the file table entry while a write was
> in progress...  It may be that ... it's *less
> likely* to happen on a system using the V7 file system, but I don't
> see that it's impossible on such a system.

And Henry Spencer concurs:
> Not impossible at all.  Running the posted test program on utzoo (a vanilla
> V7), some NULs show up.  Guy's explanation sounds right.

But looking at my (probably ancient) System V source, it appears that
while the file table entry is indeed not locked, it is only read once
the inode is locked (lines 62-70 of sys2.c, in rdwr(), in my old copy
of the source).  Therefore, the bug can, in fact, NOT happen on System
V, and appears to be limited to 4.xbsd and its commercial derivatives,
and also V7 systems (are there any left besides utzoo?:-)) (DON'T answer
that; on second thought, I'll bet there are, and I'm going to hear from
all of them.)
-- 
Jim Shankland
 ..!ihnp4!cpsc6a!\
                  rtech!jas
..!ucbvax!mtxinu!/