Xref: utzoo comp.unix.questions:12948 comp.lang.c:17719
Path: utzoo!dptcdc!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!cs.utexas.edu!uunet!auspex!guy
From: guy@auspex.auspex.com (Guy Harris)
Newsgroups: comp.unix.questions,comp.lang.c
Subject: Re: lockfile/unix/c
Keywords: c, unix, lockf
Message-ID: <1452@auspex.auspex.com>
Date: 17 Apr 89 20:54:36 GMT
References: <6307@homxc.ATT.COM> <3012@hound.UUCP>
Reply-To: guy@auspex.auspex.com (Guy Harris)
Followup-To: comp.unix.questions
Organization: Auspex Systems, Santa Clara
Lines: 28

>	Also, after opening a file with O_CREAT, I close the file, then
>reopen it with another open call, because O_CREAT will only let you
>write to the file, and I usually need read/write permission.

On all UNIX systems (note the magic word "unix" in the subject line) I
know of that support O_CREAT, opening with O_CREAT specified by itself
only lets you *read* from the file, because it's equivalent to opening
with O_CREAT|O_RDONLY, since O_RDONLY is 0 - before O_RDONLY and
company, and the 3-argument "open", existed, the second argument was
officially defined as 0 for read-only, 1 for write-only, and 2 for
read/write.

That was, quite likely, the source of the original problem, since
"lockf" grabs a write lock and thus requires that you have the file open
for writing. 

On a non-UNIX implementation of "open", it may be the case that O_CREAT
by itself only let you write to the file, but we appear to be talking
about UNIX here....

Opening with O_CREAT|O_RDWR will let you read from or write to the file.

Now, if you open the file by using the "creat" system call, the
resulting file descriptor will only let you write to the file; "creat"
is equivalent to "open" with O_CREAT|O_TRUNC|O_WRONLY specified.  One
reason to prefer the 3-argument "open" is that it doesn't force you to
have a write-only file descriptor as the result of a call that creates a
file....