Re: [hatari-devel] Problem with changes in drive ID handling

[Uwe Seimet <Uwe.Seimet@xxxxxxxxx>]

Hi,

> > Up to now my drives C:-I: were mapped to folders in the file system, and
> > the partitions of the IDE master and slave images started with drive J:.
> > This mapping does not work anymore.
> 
> That's how it already worked for ACSI, I just made IDE behave the same.

That's strange because with an ACSI hard disk image, TOS 3.06, and Hatari
1.8.0 my GEMDOS drives are mapped to C:-I: even though my image has two
partitions. Shouldn't this have been different already for ACSI?

> > Is there any way to configure the
> > old behavior, so that GEMDOS drives are assigned first?
> 
> Not with current code.  I think having GEMDOS drive after the other
> drives is more compatible, so it should be default.

Is this really more compatible? Which incompatibilities does it address?

I find the new behavior rather inconvenient, because now the available
GEMDOS drive IDs depend on the number of partitions found on the drive
images. If there are two drive images with a different of partitions, the
ID of the first GEMDOS drive changes depending on the drive image I use. Or
if I use sometimes one and sometimes two drive images I can now not rely on
fixed drive IDs for my GEMDOS drives anymore, because some of them are
ignored. If somebody uses software that remembers the path of a GEMDOS
drive (a lot of appliations do) this can even become dangerous, because
the information about saved paths is not reliable anymore but depends on
the drive images.
By the way, how do you handle DOS-compatible partitions, TOS/Windows-
compatible partitions, and byteswapped partitions? Usually the hard disk
drivers know how to handle this, and especially for TOS/Windows-
compatibility there are different approaches.

> Is there some specific use-case for mapping GEMDOS drive first?

Yes, plenty, at least in my case ;-). My AUTO folder is on GEMDOS drive
C:. Now, as soon as I use a drive image, I am forced to boot the AUTO
folder from this image because some of my GEMDOS partitions are not mapped
anymore:

Mounting IDE hard drive image /home/us/hatari/master.img
Mounting IDE hard drive image /home/us/hatari/slave.img
Drive Letter C is already mapped to HDD image (cannot map GEMDOS drive to /home/us/TT/C).
Drive Letter D is already mapped to HDD image (cannot map GEMDOS drive to /home/us/TT/D).
Drive Letter E is already mapped to HDD image (cannot map GEMDOS drive to /home/us/TT/E).
Drive Letter F is already mapped to HDD image (cannot map GEMDOS drive to /home/us/TT/F).
GEMDOS HDD emulation, G: <-> /home/us/TT/G.
GEMDOS HDD emulation, H: <-> /home/us/TT/H.
GEMDOS HDD emulation, I: <-> /home/us/TT/I.

So effectively I lose access to my GEMDOS drives C:-F:, and when I only
use one IDE image the situation is different again. Up to know I could
rely on the GEMDOS drives always being there, now some of them are
missing.

> Alternatives for implementing this could be:
> - not skipping IDE/ACSI partitions when using GEMDOS
>   multipartition setup
> - commandline/config option to set (first) GEMDOS
>   emulation drive.

There may be alternatives, but I wonder if compared to how it was before
things are probably becoming much less transparent. Even with an option
that sets the first GEMDOS drive one does not get a reliable drive order
because everything depends on the number of drive images and the number
of partitions on them. Just re-partitioning an image results in
unexpected changes.

All in all you have probably noticed that I think the new behavior is
highly problematic ;-).

By the way, when changing my image drive settings (removing the IDE images)
in the UI the Hatari development version crashes.

Take care

Uwe