| 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/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
entries.
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
DTAs.
-> I added a check for whether the DTA index is actually in use
by Hatari.
- Eero