Sometimes cannot mount 800k or HDV images

[burniouf]

AppleWin 1.30.14.0 : Why cannot mount 800k image anymore as S7D1 or S7D2 ???

[tomcw]

What's your reproducible for this?

I've tried using the AppleWin 1.30.14.0 Config's UI to mount 'Prince of Persia' and 'California Games', and both boot okay.

[burniouf]

intermitent....managed to reproduce :

[audetto]

The error is displayed when a HD is inserted as a Floppy. What are you clicking exactly to cause it?

[burniouf]

I try to select a 800k image to mount as S7D2. But it happends sometimes....sometimes it happends even if selecting a 32Mb image.

[tomcw]

Some background details:

If I try to insert an 800K image into S6D1 or S6D2 (eg. F3 or F4) then I get the message about "this UniDisk 3.5/Apple IIGS/hard-disk image is not supported", eg:

If I try to insert a 32MB image into S6D1 or S6D2 (eg. F3 or F4) then I get this message:

I need to take a look at the code, to consider how it could sometimes take the wrong code-path for FDD, when it should use the HDD code-path.

[sean-gugler]

Possibly helpful: I notice that after failing to open it as a floppy, I have to EJECT that floppy drive - even though it failed and there's apparently nothing there - before it will release the lock on that file and allow me to mount it as a HDD.

Seen in v1.30.18

[xotmatrix]

I can confirm this on v1.30.19. AppleWin is getting into a bad state when the floppy fails to mount. The fact that the floppy eject function is not disabled in the main window supports this. Once ejected, the image can be mounted as a hard disk. Attempting to eject from the configuration menu does not resolve the problem.

[tomcw]

Thanks both, I am able to reproduce this now.

Repro:

• Try to insert an 800K image into S6D1
  • this fails, but as noted, it doesn't close the file handle
• Try to insert the same 800K image into S7D1
  • this fails (since the file is still open)

NB. trying to insert for the 32MB image case doesn't have this bug, as the image is rejected earlier, as it's bigger than GetMaxImageSize(), ie. ~7MB. This regression (for the 800K image case) was likely introduced when GetMaxImageSize() was changed from 800K to 7MB, to support extremely large WOZ floppy images (#1240).