Date: Thu, 8 Apr 1999 11:24:00 +0200 (IST)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: Michel de Ruiter <Michel AT smr DOT nl>
cc: "'DJGPP workers'" <djgpp-workers AT delorie DOT com>
Subject: RE: fflush question
In-Reply-To: <B0FEA00E82A7D1118BFB00A0CC99027821323B@ARGON>
Message-ID: <Pine.SUN.3.91.990408112333.29868M-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: djgpp-workers AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk


On Tue, 6 Apr 1999, Michel de Ruiter wrote:

> But if the file is read again (via another handle) the operating system
> knows what to do: read from the system buffers. No?

DOS/Windows do this as well--mostly.  The problem you bumped into is a
very subtle case: the file in question was *created* by the program,
and the program has written too few bytes to it.  A file that's
created anew does not have any disk space reserved for it by DOS,
until such time as DOS flushes its buffers for the first time; only
then it calls the block device driver (via the IOCTL functions of Int
21h) for the disk drive which allocates disk space for the file.

Since the second open and read are issued *before* disk space is
allocated for the file, the cache doesn't have any information about
the disk clusters allocated for the file.  And since the disk cache
works on the block device (i.e. sector/cluster) level, and doesn't
know anything about the names of the files which are cached, it really
cannot associate the second open with the data from the first write.

I think if you modify the program to write e.g. 16KB of data instead of
just a few bytes, you will see that the test begins to work even without
fsync.