Altirra & Windows having a fight over a .VHD file

[andyhants]

Now as I'm typing this it seems obvious but anyway here goes. 

 

So I've eventually (mostly) sussed setting up Hard Drives under Altirra running the U1MB & SIDE2 combo. So max partition sizes of 65,536 512 byte sectors for A8 DOS, using .VHD files as CF disks under SIDE2 in Altirra, using ADR tools FDISK etc all good. Also want to have HDs for swapping files between Atari & Windows environments so sussed how to include FAT16 partitions in the APT & include FATFS.SYS in the SDX CONFIG.SYS so I can have a partition that is visible by SDX & Windows.

 

Anyway all up & running but I can't get Windows & Altirra to recognise the VHD at the same time. I've setup a VHD File under Altirra then used FDISK to create FAT & APT partitions & used Windows Disk Management to mount & format the FAT16  partition in the VHD file as F: (already set up under FDISK as D5:). But after I've done the Windows Disk Management piece to mount the VHD as F: I then re-boot the Altirra instance & it forgets the VHD File association in Altirra 3.2 under System > Configure System > Devices > SIDE2, the VHD file has disappeared & when I try to re-associate it I get the message 'The process cannot access the file because it is being used by another process'.

 

If I then reboot & got straight into Altirra I can then go through the Configure System & re-associate the VHD file. Windows though doesnt retain the F: association with the VHD file. Re-booting Altirra & hitting L at the U1MB splash screen - sure enough the SIDE LOADER does recognise D5: & the range of test files I copied to it under Windows (ATRs, XEXs etc). So my guess is you can't have both the Windows F: VHD mount running at the same time as Altirra having the SIDE2 VHD associsation running. Is that true ? If so its a pain as it appears I would need to re-create the Windows F: mount under Disks Management each time I wanted to use it (Windows can't seem to remember it from session to session) & then do the same for re-creating the VHD SIDE2 association in Altirra. It seems there an exclusive use flag or something assocaited with the VHD file that says 'hands off its being used by somethign else' (whatever the last app was). Has anyone got these working concurrently ?

 

Also along the same lines it seems to me a much easier thing to achieve the same goal is to use the Altirra fucntionality under the Disk Drives Alt-D  function 'Mount folder as virtual SpartaDOS folder'. Seems to do the same sort of thing without any of the hassle  - although not accessible by SIDE LOADER ?

[flashjazzcat]

1 minute ago, andyhants said:

So my guess is you can't have both the Windows F: VHD mount running at the same time as Altirra having the SIDE2 VHD associsation running. Is that true ?

As far as I'm concerned, yes. Altirra appears to need exclusive access to the VHD. It's not really a big deal (I use VHDs a LOT while developing the U1MB/SIDE firmware); normally, I'll just unmount the VHD from Altirra, right-click and mount it, copy stuff into one of the FATs, then 'Eject' one of the drives (which causes the whole VHD to unmount). Then I re-mount in Altirra. To be honest, drilling down into the device dialog in Altirra is the most click-heavy part of the entire process.

4 minutes ago, andyhants said:

Also along the same lines it seems to me a much easier thing to achieve the same goal is to use the Altirra fucntionality under the Disk Drives Alt-D  function 'Mount folder as virtual SpartaDOS folder'. Seems to do the same sort of thing without any of the hassle  - although not accessible by SIDE LOADER ?

Altirra virtual folders are a great way of sharing data between the host and the emulated machine, although PCLINK (in SDX) is the best solution of all (since it works R/W; this is supported in Altirra too). The SIDE loader is hard-coded to work with the IDE HDD, however.

[phaeron]

As you've found out, you can't double-mount .VHD files. There are too many ways that this can go wrong because whatever is reading the VHD file will be unaware of changes made by another program or the OS writing to it, and when this involves VHD structures it would get pretty nasty.

 

There is a way around this, which is that you can run Altirra as administrator and instead map the drive volume that Windows has created for the mounted VHD image. This works because then Windows is handling the VHD access in all cases. However, there's still no guarantee that you won't see corruption on the disk in the emulator, because there's no synchronization with the Windows FAT32 filesystem driver -- the DOS running in the emulator can see half-changed data structures on the FAT32 disk. The virtual SpartaDOS disk handles this better because it controls the filesystem that SpartaDOS is seeing and changes the volume serial number on the disk, which signals SpartaDOS to treat it as a new disk and flush cache buffers.

 

[TGB1718]

15 hours ago, andyhants said:

'The process cannot access the file because it is being used by another process'.

I've found this to happen even though I never tried to mount in Windows at the same time, I created a new VHD,

partitioned it, copied .ATR's etc onto the FAT partition, disconnected the VHD in Windows, but then get

that same message when trying to mount in Altirra, I've checked process explorer and nothing has the file,

it just seems Windows keeps a lock on VHD's sometimes, the only way to release the lock is to reboot Windows.

 

[andyhants]

18 hours ago, flashjazzcat said:

As far as I'm concerned, yes. Altirra appears to need exclusive access to the VHD. It's not really a big deal (I use VHDs a LOT while developing the U1MB/SIDE firmware); normally, I'll just unmount the VHD from Altirra, right-click and mount it, copy stuff into one of the FATs, then 'Eject' one of the drives (which causes the whole VHD to unmount). Then I re-mount in Altirra. To be honest, drilling down into the device dialog in Altirra is the most click-heavy part of the entire process.

Altirra virtual folders are a great way of sharing data between the host and the emulated machine, although PCLINK (in SDX) is the best solution of all (since it works R/W; this is supported in Altirra too). The SIDE loader is hard-coded to work with the IDE HDD, however.

Great thanks Jon. Good tip (as ever) on the Windows-side right-click to Mount / Eject VHDs.

 

Actually makes more sense now I've thought more about it as you are effectively using the VHD file as though it was a real CF CArd that needs Mounting / Ejecting to & from the PC & A8 SIDE2 Cart.

[andyhants]

2 hours ago, TGB1718 said:

I've found this to happen even though I never tried to mount in Windows at the same time, I created a new VHD,

partitioned it, copied .ATR's etc onto the FAT partition, disconnected the VHD in Windows, but then get

that same message when trying to mount in Altirra, I've checked process explorer and nothing has the file,

it just seems Windows keeps a lock on VHD's sometimes, the only way to release the lock is to reboot Windows.

 

If you follow Jon's advice above it should work ok. It helps to think of the VHD file as an actual CF Card that needs physcially moving from between the PC & SIDE2 cart.

[andyhants]

9 hours ago, phaeron said:

As you've found out, you can't double-mount .VHD files. There are too many ways that this can go wrong because whatever is reading the VHD file will be unaware of changes made by another program or the OS writing to it, and when this involves VHD structures it would get pretty nasty.

 

There is a way around this, which is that you can run Altirra as administrator and instead map the drive volume that Windows has created for the mounted VHD image. This works because then Windows is handling the VHD access in all cases. However, there's still no guarantee that you won't see corruption on the disk in the emulator, because there's no synchronization with the Windows FAT32 filesystem driver -- the DOS running in the emulator can see half-changed data structures on the FAT32 disk. The virtual SpartaDOS disk handles this better because it controls the filesystem that SpartaDOS is seeing and changes the volume serial number on the disk, which signals SpartaDOS to treat it as a new disk and flush cache buffers.

 

Thanks phaeron. Bit too scared to do the admin thing. I'm following Jon's advice above.