Date: Thu, 8 Apr 1999 21:26:07 -0400
Message-Id: <199904090126.VAA27042@envy.delorie.com>
From: DJ Delorie <dj AT delorie DOT com>
To: djgpp-workers AT delorie DOT com
In-reply-to: <199904090117.VAA28719@spock2.ECE.McGill.CA> (message from Alain
	Magloire on Thu, 8 Apr 1999 21:17:36 -0400 (EDT))
Subject: Re: fflush question
References:  <199904090117 DOT VAA28719 AT spock2 DOT ECE DOT McGill DOT CA>
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


> 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);

Yes, that should fail also.  In which case, we'd have to sync all
writes, not all fflushes, which would make performance horrible.  It's
not DJGPP's fault.  It's DOS's fault.  The best we can do is work
around the bug when we can.

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

However, I'm trying to second-guess the programmer by putting it only
in fflush().  We can't easily fix the above program, but if the
programmer calls fflush() we can assume they're concerned about a
synchronization problem, and do our best to accomodate them.

> DJGPP doesn't maintain a consistent view of the file.

Like I said, it's not DJGPP it's DOS.  Turbo-C should show the same
behavior (can someone verify this?) with your example.

> fd = create();
> unlink(fd);

If you do this in DOS, you'll corrupt your hard drive (again, it's
DOS's fault).  There's a stdio.h function for creating temps that
automatically deletes the file *after* you close it.  Use that
instead.

Note: unlink takes a file name, not a file handle.