From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,3cd3b8571c28b75f
X-Google-Attributes: gid103376,public
X-Google-ArrivalTime: 2003-09-05 19:10:22 PST
Path: 
 archiver1.google.com!news1.google.com!newsfeed.stanford.edu!cyclone.bc.net!tdsnet-transit!newspeer.tds.net!news.binc.net!kilgallen
From: Kilgallen@SpamCop.net (Larry Kilgallen)
Newsgroups: comp.lang.ada
Subject: Re: A Customer's Request For Open Source Software
Date: 5 Sep 2003 21:10:19 -0500
Organization: Berbee Information Networks Corporation
Message-ID: <D1upWhxUuOLF@eisner.encompasserve.org>
References: <3F44BC65.4020203@noplace.com>
 <20030822005323.2ff66948.david@realityrift.com>
 <vkc1b.26226$Cd2.21231@nwrdny01.gnilink.net>
 <Prv1b.3720$PJ2.319043@news20.bellglobal.com>
 <e2e5731a.0308221829.3d16a7b@posting.google.com> <3F4828D9.8050700@attbi.com>
 <bRv3b.692$c12.9302@newsfep4-glfd.server.ntli.net> <3F4EA616.30607@attbi.com>
 <e2e5731a.0308301101.7abab808@posting.google.com>
 <3F512BD1.8010402@attbi.com>
 <e2e5731a.0308311504.7c18e530@posting.google.com>
 <3F52AA5F.8080607@attbi.com> <e2e5731a.03090Organization: LJK Software
NNTP-Posting-Host: eisner.encompasserve.org
X-Trace: grandcanyon.binc.net 1062814127 6246 192.135.80.34 (6 Sep 2003
 02:08:47 GMT)
X-Complaints-To: abuse@binc.net
NNTP-Posting-Date: Sat, 6 Sep 2003 02:08:47 +0000 (UTC)
Xref: archiver1.google.com comp.lang.ada:42199
Date: 2003-09-05T21:10:19-05:00
List-Id: <comp.lang.ada>

In article <Ln36b.22618$su.611773@news20.bellglobal.com>, "Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> writes:

> Control is where it is at. With block devices you can only:
> 
> 1) leave it up to the O/S when to flush out writes
> 2) call sync(2) and have all dirty blocks written out
> 3) call fsync(3) and have all of your own blocks related
>     to the file descriptor written out.

You seem to be presuming some Unix system.  Not all operating systems
have those limitations.

>> Most operating systems will allow you to wait until the data are
>> even if you are using the file system, so there is no difference with
>> respect to the durability of data.
> 
> With UNIX, a return from write(2) is only a promise that
> it will someday be written. No specific timeline is
> guaranteed (see above). I don't expect it is much different
> with win32 systems.

It is certainly quite different with OpenVMS.