Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!lll-crg!mordor!sri-spam!sri-unix!hplabs!decwrl!sun!guy
From: guy@sun.uucp (Guy Harris)
Newsgroups: comp.unix.questions,comp.unix.wizards,comp.databases
Subject: Re: O_SYNC option in SVR3 open system call
Message-ID: <9119@sun.uucp>
Date: Mon, 10-Nov-86 15:31:44 EST
Article-I.D.: sun.9119
Posted: Mon Nov 10 15:31:44 1986
Date-Received: Tue, 11-Nov-86 06:25:28 EST
References: <5922@gatech.EDU>
Organization: Sun Microsystems, Inc.
Lines: 23
Xref: mnetor comp.unix.questions:7 comp.unix.wizards:11 comp.databases:1

> 	O_SYNC	When opening a regular file, this flag affects subsequent
> 		writes. If set, each write (2) will wait for both the file
> 		data and file status to be physically updated.
> 
> Does anybody out there knows if this wait is for real or is the same BSD
> idea of the "fflush" in which blocks are merely "scheduled" and the call 
> returns as if they were actually written to the device. 

The wait is for real.  But what is this "same BSD idea of the 'fflush'"?
First of all, "fflush" is a part of standard I/O, and if you do an "fflush"
it ends up doing "write" calls, so the notion of a delayed or asynchronous
write is *not* a property of "fflush", but a property of "write".  Second,
"fflush" isn't a "BSD idea" at all; it, like a lot of other things in 4BSD,
dates back to V7 (actually, it dates back even further than that) and, as
such, should be called an "AT&T idea".  Third, the notion of a delayed or
asynchronous write also considerably predates even 1BSD.  Finally, there
*is* a "BSD idea" relating to this; however, it is the idea of an "fsync"
call to flush blocks to the device, and it *does* wait (for real) until the
blocks are actually written to the device.
-- 
	Guy Harris
	{ihnp4, decvax, seismo, decwrl, ...}!sun!guy
	guy@sun.com (or guy@sun.arpa)