From: Alain Magloire <alainm AT rcsm DOT ece DOT mcgill DOT ca>
Message-Id: <199904090117.VAA28719@spock2.ECE.McGill.CA>
Subject: Re: fflush question
To: djgpp-workers AT delorie DOT com
Date: Thu, 8 Apr 1999 21:17:36 -0400 (EDT)
In-Reply-To: <Pine.SUN.3.91.990408112333.29868M-100000@is> from "Eli Zaretskii" at Apr 8, 99 11:24:00 am
X-Mailer: ELM [version 2.4 PL25]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
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

Bonjour

> 
> 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.
> 

So this may also trigger the bug, if I don't fsync() ?
char d, c = '1';
a = open ("foo", O_CREAT|O_WRONLY, MODE);
write(a, &c, 1);
b = open ("foo", O_RDONLY);
read (b, &d, 1);

IF yes, so putting fsync() in fflush() may correct the problem
if I use the stdio API but doesn't fix the bug.
This seems to be a peculiarity of DJGPP then a stdio implementation
bug.  DJGPP doesn't maintain a consistent view of the file.

The explanation makes me wonder about a practice use by lots
of Unix programmers for temp files. A file is created and deleted
fd = create();
unlink(fd);
Even if the file is unlink .i.e not visible in the file system
namespace, you can still read/write to it. This is common practice.
Is it possible on DJGPP ?

-- 
au revoir, alain
----
Aussi haut que l'on soit assis, on est toujours assis que sur son cul !!!