Re: [hatari-devel] GEMDOS file buffer flush problem?

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi,

On tiistai 26 helmikuu 2013, Douglas Little wrote:
> When the listing file is large, it is not always completely written to
> the disk when Devpac3 has finished assembling. The file reaches a (very
> round-looking) size of 1536kb and is truncated. I can make a backup copy
> of this file, and exit Devpac3, and the file remains at the same
> truncated size.
> 
> When I then exit Hatari, the file commits fully to 1544k and is no longer
> truncated.

Host C-library buffers Hatari's fwrite()s.  They're flushed when
the corresponding FILE* is closed, which happens when:
- Atari program closes the file handle
- Emulation is reseted
- Hatari exits


> Apart from being quite annoying (it means I have to keep restarting
> Hatari each time I want to generate a symbol file)

If this is about data not being flushed because Atari program doesn't
close its output file, reseting the emulation should be enough.  All
GEMDOS HD emulation file handles are closed on reset.


> it's also a little scary - what else might not be getting fully
> committed to the GEMDOS share during a Hatari session?
>
> TBH I don't know if this is a Devpac bug or a Hatari problem - but I
> imagine it could be a bit of both. If the file only flushes properly when
> Hatari exits, there must be either pending writes (Hatari)

Hatari doesn't seem to do fflush() after writing GEMDOS Fwrite() call
content to the corresponding file with fwrite().

Attached (untested) patch adds the fflush(), does it fix the problem?


> or a pending file closure (Devpac).

You can check whether Devpac actually closes the file with GEMDOS tracing.
Just start Hatari with "--trace gemdos" or enable it from the debugger
with "trace gemdos".  ("trace none" disables tracing)


> In any case it would seem there is a difference in behaviour between
> Hatari and a real Falcon for this situation so it may be worth
> investigating.

I'm pretty sure that at least older TOS versions don't buffer their writes,
so I think missing fflush() in Hatari GEMDOS code is actually a bug.


	- Eero

diff -r bd5489c8d4b6 src/gemdos.c
--- a/src/gemdos.c	Tue Feb 26 11:00:00 2013 +0200
+++ b/src/gemdos.c	Tue Feb 26 19:15:29 2013 +0200
@@ -1921,6 +1921,7 @@
 	Uint32 Addr;
 	Sint32 Size;
 	int Handle;
+	FILE *fp;
 
 	/* Read details from stack */
 	Handle = STMemory_ReadWord(Params);
@@ -1956,8 +1957,9 @@
 		return true;
 	}
 
-	nBytesWritten = fwrite(pBuffer, 1, Size, FileHandles[Handle].FileHandle);
-	if (ferror(FileHandles[Handle].FileHandle))
+	fp = FileHandles[Handle].FileHandle;
+	nBytesWritten = fwrite(pBuffer, 1, Size, fp);
+	if (ferror(fp))
 	{
 		Log_Printf(LOG_WARN, "GEMDOS failed to write to '%s'\n",
 			   FileHandles[Handle].szActualName );
@@ -1965,6 +1967,7 @@
 	}
 	else
 	{
+		fflush(fp);
 		Regs[REG_D0] = nBytesWritten;      /* OK */
 	}
 	return true;