Re: [hatari-devel] GEMDOS emulation and host-side DTA caching

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

This is a multi-part message in MIME format.

Hi,

On 2/16/20 11:21 AM, Christian Zietz wrote:
> seen here: <http://www.atari-forum.com/viewtopic.php?f=51&t=38406>. A
> user wanted to copy a complex directory tree from a GEMDOS emulated
> drive. The recursive Fsfirst/Fsnext required to do so exhausted Hatari's
> tiny [1] host-side DTA cache, therefore resulting in only a partial copy
> operation.
>
> A simplified test case is attached. It needs to be run from a GEMDOS
> drive C: with some files on it. Also the folder C:\TEST has to exist and
> it too needs to contain some files. Expected behavior is getting a file
> name from C:\, but the test program will output a file name from C:\TEST
> instead.
>
> I don't have a solution for this; I just wanted to bring this up to
> discussion. Ideas I came up with:
>
> - Simply increasing the cache size, like the user did. Only makes the
> issue less likely, but easy to implement.
>
> - Somehow cram all host-side state into the Atari-side DTA, more
> specifically its 'reserved' field. Probably not doable, also dangerous
> because the emulated program could corrupt the host-side state.
>
> - Instead of linearly incrementing the index of the host-side DTA cache
> entry, using a hash of the Atari-side address of the DTA as index into a
> (sufficiently large) array. Collisions can still occur, but if an
> application (like my test program or the Desktop) reuses DTAs, this
> makes sure that an unneeded cache entry is overwritten instead of a
> potentially still needed one.

Thanks for the tester!

I think the attached patch fixes this issue.

(On quick testing it works with your test-case,
but I don't have anything to test it more.)


	- Eero