| 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/14/18 7:18 AM, Thorsten Otto wrote:
On Freitag, 14. Dezember 2018 01:33:14 CET Eero Tamminen wrote:
I.e. Atari program needs to call Fsfirst() before further Fsnext()
calls will provide matches.
Erm, no. Fsfirst already returns the information about the first file found.
> Also, a common use of it to check for a files existence, so sometimes
> Fsnext is not called at all.
Yes, that's how TOS works / is used.
What I was saying is that after restoring memory snapshot, GEMDOS HD
internal DTA cache [1] has (currently) bogus data. As result, Fsnext()
calls won't work correctly (except by pure luck) until program calls
Fsfirst().
What I was thinking of doing, was just invalidating all entries
cached by Fsfirst(), so Fsnext() calls will deterministically return
"no more files" until program calls Fsfirst() for given DTA again.
Fsfirst() is no problem because that's the thing initializing
the internal DTA cache for given DTA index.
[1] How Hatari works:
When Fsfirst() is called, Hatari maps the pattern to host path, scans
all files there, and caches sorted list of ones that match the given
pattern (after host->atari string conversion & truncating file names).
This is the internal DTA file match cache.
When Fsnext() is called, it takes next entry from the cached entries,
stats the related host file, converts host file attribs to Atari ones,
and stores the result to Atari program's DTA.
I guess the reasons why all scanning is done in Fsfirst() phase, is:
* sorting the file names provides users some way to control order
in which emulated Atari accesses the files (sorted file names
are returned in alphabetical order).
* doing scanning only once, speeds up Fsnext() calls and guarantees
that Fsnext() continues from place where it was left (although
underlying directory contents would change, regardless of whether
those changes are to files visible to inside emulation or not)
I think that if DTA / Fsnext() state needs to be saved & restored in
memory snapshots, it would be better to remove this caching first.
- Eero