Re: [hatari-devel] opened filehandles not saved/restored in memory snapshot with gemdos hd ?

[ Thread Index | Date Index | More lists.tuxfamily.org/hatari-devel Archives ]


Hi,

On 12/9/18 2:41 PM, Nicolas Pomarède wrote:
while debugging a program, I noticed that this program didn't work correctly anymore once it was started from a gemdos hd, saved and restored from a memory snapshot.

This program is opening an MP2 music file at start and read blocks of 64K bytes in a loop to send them to the dsp, using GEMDOS FREAD $3F.

From what I see, when memory is saved during playback, the content of FileHandles[] is not saved for all opened files having bUsed=true. So on restore, even if the file handle is still opened from TOS' point of view, it's not opened anymore from the host OS' point of view and FREAD returns error -37 "invalid file handle"

Shouldn't the content of FileHandles[] be saved and then when restoring reopen all "szActualName" files' path for which bUsed is true ? Or could this have some bad side effects ?

I can't think of any outright.

A problem of course is if file cannot be found any more from
the same host path.  I'm not sure whether Hatari should:
* Give user error about restore failing and either abort, or reset
  emulation as it's in inconsistent state
* Warn user about missing file(s) and tell that GEMDOS HD state
  doesn't match restored state, but still continue


It's might not be a common case that programs keep files open for such a  long time, but saving/restoring this state would be handy.

Can you propose a patch?


	- Eero



Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/