Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!uunet!dg!rec
From: rec@dg.dg.com (Robert Cousins)
Newsgroups: comp.unix.questions
Subject: Re: fopen ( ..., "a" ) --- how does the "a" work?
Message-ID: <236@dg.dg.com>
Date: 7 Dec 89 14:13:57 GMT
References: <3250@hub.UUCP>
Reply-To: uunet!dg!rec (Robert Cousins)
Organization: Data General, Westboro, MA.
Lines: 43

In article <3250@hub.UUCP> 6600pete@hub.UUCP writes:
>When one opens a file under *most* flavors of UN*X (I realize this is
>the kind of thing that will be system-dependent, though it oughtn't)
>with fopen ( ..., "a" ), the file mark is supposed to be moved to EOF
>before every write. Now, how is this done? Are there two system calls,
>one to move the file mark and one to do the write, or is there one
>system call, "append"? If the latter, then this is an easier solution
>for a problem I have than figuring out how to do record locking.
>-------------------------------------------------------------------------------
>Pete Gontier   : InterNet: 6600pete@ucsbuxa.ucsb.edu, BitNet: 6600pete@ucsbuxa
>Editor, Macker : Online Macintosh Programming Journal; mail for subscription
>Hire this kid  : Mac, DOS, C, Pascal, asm, excellent communication skills

It is important to point out that use of "a" mode is some circumstances
will not work as anticipated.  This is in any environment in which NFS
is used and two programs are writing to the same file without locking
the records in an effective fashion.  The reason for this is that the
NFS protocol does not have any concept of "guaranteed append" so the
client operating system translates append writes into something more
like lseek-write combinations which are more-or-less atomic.  The problem
with this is that the client operating system has its own idea of where
the end of the file is and therefore where to append.  If another client
has appended something to the file in the mean time it could be lost.
 
This all comes from the fact that NFS is a stateless protocol.  Each
NFS operation carries with it all (or atleast is supposed to) information
the server needs to complete the operation.  Furthermore, all operations
are idempotent and therefore can be repeatedly performed.  (This is
how they get away with using UDP/IP.)  In effect, an NFS write translates
into a "write x bytes in file y starting at location z."  If the same
write is performed several times (since UDP/IP can deliver a request
multiple times), the data file's contents are the same.
Had this been a stateful protocol ("append x bytes to file y") and multiple
requests were delivered, one could easily see a datafile with a bad
case of the "stutters."

Robert Cousins
Dept. Mgr, Workstation Dev't.
Data General Corp.

Speaking for myself alone.

executions took place