Mail Archives: djgpp/2004/10/22/07:15:25
Brian Inglis wrote:
> On Thu, 21 Oct 2004 18:06:19 -0230 in comp.os.msdos.djgpp, Jason Mills
> <jmills AT cs DOT mun DOT ca> wrote:
>
>
>>Jason Mills wrote:
>>
>>>After a few hours or debugging, I reached the conclusion
>>>that to flush a C++ fstream, you must either fstream::close(),
>>>or call fflush(NULL). Is this normal? Or is it a bug?
>>
>>Actually, the above is not correct. Sorry.
>>
>>After more tests, I discovered that fstream::flush() and fflush(NULL)
>>both will not flush the stream if I am writing rapidly to the stream.
>>If I sleep(), (maybe if I a do other work, I have not checked)
>>the stream is eventually flushed. Can someone explain?
>
>
> How are you testing this? From another window, or another system on a
> network?
In the program, I noticed stat() returns a file size of 0 until the
file is closed, or a sleep() is called. You could simply test this from
another window as well (if you mean doing a 'dir' in that window).
> The flush() operations just write the program's buffer(s) to the DOS
> file buffer(s), it doesn't write the DOS file buffer(s) to the file
> system disk cache, nor flush the file system disk cache to the disk
> immediately. You need to call fsync(), and/or sync(), and/or
> _flush_disk_cache(), to do the rest.
I was unaware of this because the program is being ported from Linux,
where it worked flawlessly: fsync(), sync(), etc. is apparently
unecessary.
>
> Even then I'm not sure that Windows makes cache updates visible
> immediately (like Unix) to other processes or systems on a network
> before the cache is flushed to disk and/or the file is closed,
> depending on when it updates the clusters in the FAT or blocks used in
> the FS.
"Like UNIX" is the key. The program is port of a linux program. There
the file size is reported correctly as soon as a flush is called. (see
related reply to Hans-Bernhard Broeker for details of what I'm trying
to do)
Jason
- Raw text -