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

["Roger Burrows" <anodyne@xxxxxxxxxxxx>]

On 19 Feb 2020 at 0:49, Eero Tamminen wrote:

> Hi,
> 
> On 2/18/20 10:02 PM, Christian Zietz wrote:
> >>> - Simply increasing the cache size, like the user did.
> >>>    Only makes the issue less likely, but easy to implement.
> >>
> >> I'm inclined to this solution, but I'm wondering
> >> about the gemdos.c code comments:
> >> ----------------
> >> #define  BASE_FILEHANDLE     64    /* Our emulation handles - MUST not
> >> be valid TOS ones, but MUST be <256 */
> >> #define  MAX_FILE_HANDLES    32    /* We can allow 32 files open at once
> */
> >> ----------------
> > 
> > Now I'm confused, sorry. The DTA cache size has nothing to do with the
> > number of file handles that Hatari's GEMDOS emulation allows. DTAs are
> > used for Fsfirst/Fsnext, while file handles are only used when a file is
> > actually opened. Changing MAX_FILE_HANDLES won't solve the problem that
> > I (or rather the user) reported. MAX_DTAS_FILES is the issue here.
> > 
> > So, what did I misunderstand in your post?
> 
> Sorry, I had bad reading comprehension
> (from too little sleep last night).
> 
> Same comments should apply pretty well to DTAs
> too though.
> 
> I also think Hatari code should check, log and
> return error if there aren't enough DTAs, instead
> of silently wrapping around...
> 
> Do you know what the EmuTOS DTA limits are
> and what it does when they're exceeded?
> 
Under EmuTOS (and AFAIK under Atari TOS too), the number of DTAs that a program 
can have is only limited by memory.  The DTA's reserved area maintains the info 
required to link that DTA to a specific filespec and directory. See DTAINFO in 
bdos/fs.h for specifics.

For EmuDesk and the Atari desktop, a desktop recursive copy/move takes one DTA 
per level of recursion, and the number of levels in a copy/move is limited to 
12.

Roger