Re: [hatari-devel] Duplicate drive image file issue

[ Thread Index | Date Index | More lists.tuxfamily.org/hatari-devel Archives ]


This is a multi-part message in MIME format.
Hi Uwe,

I've tested the attached patch(es) to fix
the issue you found.

Could you verify?

(I think I'll push it only after release though.)


	- Eero

On 10/30/20 9:55 AM, Uwe Seimet wrote:
Any news on this?

Best regards

Uwe

No, I'm afraid nothing has changed, the issue is still there.

Best regards

Uwe
>>
On 11/3/19 9:33 PM, Uwe Seimet wrote:> Hi Roger,
On 3 Nov 2019 at 8:17, Uwe Seimet wrote:

For IDE HD 0 I have configured a drive image to be used. When I select
the same image file for ACSI HD 0 and reset Hatari, Hatari reports
"Locking HD file for writing failed" and TOS only sees IDE HD 0, but not
HD ACSI 0. So far, so good.
  >>>
Now I eject the file for IDE HD 0, so that the image file is configured
for ACSI HD 0 only. After rebooting there is no HD available for TOS
at all, even though ACSI HD 0 is the only drive configured with an image
file. Looks as if Hatari has not noticed that there is no image file
conflict anymore but still ignores the (only) assigned image.

Are you sure this is not a byte-swapping problem?  My ACSI image and IDE image
are byte-swapped with respect to each other.
  >
  > Yes, I'm sure, because if I avoid the locking issue by applying the
  > change (i.e. using the image file for ACSI instead of IDE) in a single
  > step in the UI, everything is fine.

I think I see the problem.  In:
	change.c::Change_CopyChangedParamsToConfiguration()

UnInit for IDE & ACSI/SCSI drives is called only if the status of drives
is changed *and* at least on of the changed drives is still used,
i.e. they're unlocked only if IDE or ACSI needs to re-initialized.

Attached quick patch does unInit separately for them.  Does that fix
the problem?






Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/