"cannot create drive from file" while it works in the original DOSBox

[lwcorp]

Describe the bug

DOSBox-X fails to run IMGMOUNT a over a certain IMG file, while it does work in the original DOSBox.

Steps to reproduce the behaviour

1. Download Kryoflux for Windows and extract
2. Enter https://archive.org/details/WWFEuropeanRampageTourOcean199235Kryoflux.7z
3. Download the Kryoflux Dump there
4. Use Windows CMD to enter kryoflux_3.00_windows\dtc\DTC_x64\
5. Use KryoFlux COMMAND LINE EXAMPLES of Create formatted image files in deviceless mode (i.e., using stream files) to create a standard IMG file, e.g.
   dtc -f"WWF European Rampage Tour (Disk 1)(Ocean)(1992)(3,5'')\track00.0.raw" -i0 -fdisk1.img -i4 -m1
dtc -f"WWF European Rampage Tour (Disk 2)(Ocean)(1992)(3,5'')\track00.0.raw" -i0 -fdisk2.img -i4 -m1
6. Note the second command produces errors:
   00.0 : Bad sector found
00.0 : Read operation failed
00.1 : Bad sector found
00.1 : Read operation failed
01.0 : Bad sector found
01.0 : Read operation failed
01.1 : Bad sector found
01.1 : Read operation failed
02.0 : Bad sector found
02.0 : Read operation failed
02.1 : Bad sector found
02.1 : Read operation failed
03.0 : Bad sector found
03.0 : Read operation failed
03.1 : Bad sector found
03.1 : Read operation failed
04.0 : Bad sector found
04.0 : Read operation failed
04.1 : Bad sector found
04.1 : Read operation failed
7. Run imgmount a disk2.img
8. It works in DOSBox, but in DOSBox-X Drive A isn't mounted with the message cannot create drive from file

Expected behavior

Drive A should be loaded and usable

What operating system(s) this bug have occurred on?

Windows 10 22H2 64-bit

What version(s) of DOSBox-X have this bug?

1. 2024.03.01, Windows SDL2, 64-bit
2. 2023.09.01, MingGW SDL2, 64-bit
3. 2023.09.01, Windows SDL1 64-bit
4. 2023.09.01, MingGW SDL1, 64-bit

Used configuration

No response

Output log

LOG: No geometry

Additional information

1. There's no such issue with the first file (i.e. disk1.img)
2. It also fails with -t floppy (which isn't required by DOSBox-X but is by DOSBox)
3. There's no such issue in the original DOSBox, it just shows in Drive A a file called WWF.2:
   

Have you checked that no similar bug report(s) exist?

• I have searched and didn't find any similar bug report.

Code of Conduct & Contributing Guidelines

• I agree to follow the code of conduct and the contributing guidelines.

[maron2000]

PR #4900 may fix the problem, however, the floppy image should be justified that it is really dumped correctly.

[lwcorp]

Thanks! It seems you linked the issue to itself, so you may want to edit (update: thanks for fixing!).
How unfortunate that it missed the last release by 2 weeks. I wish you to try it, but pre-releases like https://github.com/joncampbell123/dosbox-x/releases/tag/dosbox-x-v0.84.3 are quite rare, and I've found no instructions how to try it directly from the source code.

Regarding the "however", what do you mean "justified"? It's likely corrupted on purpose as a type of copyright protection.

So basically did you add extra protection over DOSBox until with this PR took it down a notch?

[maron2000]

The image size of disk2.img converted is 900kB, which I think is incorrect.
It should be 720kB, as same as disk1.img.

[lwcorp]

Well, since I can't test it, can you try to install the installer from disk1, and swap to disk when requested, then see if the game works after the installation?

[Torinde]

You can try the developer builds from here, they have the latest code.

[lwcorp]

Any idea why does one must log in in order to download?
In any case, it gets stuck in disk1. You can run install.exe but it just beeps when trying to approve the path.
Meanwhile DOSBox has no issue there, and thus reaches the end of the installation of disk1 (where you can't proceed to disk2 since DOSBox doesn't support swapping floppy disks).

[lwcorp]

In any case, it gets stuck in disk1. You can run install.exe but it just beeps when trying to approve the path. Meanwhile DOSBox has no issue there, and thus reaches the end of the installation of disk1 (where you can't proceed to disk2 since DOSBox doesn't support swapping floppy disks).

Can you reopen?

[lwcorp]

While it wasn't re-opened it just made it to production. Now you can proceed to disk2 only to end up with "FATAL installation error FF44", which opens the debugger at "DOS fatal memory error: Corrupt MCB chain".

All I can say is that it does work if instead of using KryoFlux's official converter one uses DOSBox-TC's flux2tc --consolidate track00.0.raw diskX.tc. But this converts to TC files which DOSBox-X doesn't support...

[lwcorp]

A new production version was released, and took us back in time.
Now it beeps again, just like back in dev and unlike in the last official release (which still happens if you copy the disks' contents to c and run install.exe from there).
Did you undo something?

Meanwhile, I've noticed after it beeps (instead of asking to switch to disk2) it doesn't get fully stuck but lets you click escape. If you do this, you get taken back to DOS where it states Could not find any fixed disk's... (I assume it means disks and not disk's), which is weird because how did it manage to run install.exe if not from a fixed disk?