Date: Thu, 8 Apr 1999 21:26:07 -0400 Message-Id: <199904090126.VAA27042@envy.delorie.com> From: DJ Delorie 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.