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

[ Thread Index | Date Index | More Archives ]


On 12/10/18 10:25 AM, Nicolas Pomarède wrote:
Le 09/12/2018 à 23:00, Eero Tamminen a écrit :
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

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 :)

Ok, I started looking into it.

It will need to handle also forced file handles and cached DTA

Former can be saved/restored as-is, but I think I'll just invalidate
info for all (256) DTA entries as they can contain arbitrary number of
dynamic string allocations, which would make DTAs use "random" amount
of space from memory snapshot.

I.e. Atari program needs to call Fsfirst() before further Fsnext()
calls will provide matches.  I don't think that's a problem unless
one makes a snapshot in middle of file selector or desktop directory
window refreshing.

Current DTA handling can do something bogus because memory snapshot
restore will restore Hatari magic values to Atari side DTAs, but their
DTA index can currently refer to something unused in internal Hatari
-> I added a check for whether the DTA index is actually in use
   by Hatari.

	- Eero

Mail converted by MHonArc 2.6.19+