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 ]


Le 09/12/2018 à 23:00, Eero Tamminen a écrit :
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


Hi

I'd rather display a warning and continue the restore anyway. In all cases, gemdos.c will report an error to TOS (as it's already the case), so nothing should crash, just a bad filehandle error that the emulated program should handle. the seek/f_pos of each host's filehandles should also be saved along with the path to be sure the file is reopened and restored at the same position.


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?

not at the moment, sorry. But I will gladly test any patch that could be sent :)

Nicolas



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