Drastic file resizing with multiple hard disks

[PythonBlue]

Another bug report, and this one has even occassionally happened in the newer versions of RetroArch.

I realize this is probably a deprecated situation from what I've read in the core documentation, and in retrospect, there's a chance this issue is also related to some of the notes mentioned in #290 , but I'm saying it anyway: having found a way to mount two hard drive images at once, one being in the D drive, I've occassionally noticed a drastic file increase after use of whatever's mounted in the D drive. I'd verify how it happens, but the issue is so severe that when I formatted a D drive, for instance, it must've increased in size on the host by 10 GB with that action alone! Strangely enough, the image does still read fine after the increase, but it's very obviously a problem for the storage of the host system.

If it helps with if you have the storage to try to reproduce on your own, all tests with the issue involved use of a .conf file using an IMGMOUNT command for the D drive (I confirmed the geometry of the images in advance, so thankfully, it does mount fine). I didn't confirm if this was the case for all situations, but at least some conf files also made use of the new REMOUNT command with the C drive set to another image afterwards.

[schellingb]

DOSBox doesn't support any kind of compressed .IMG files so the files are always raw. Meaning having a 2GB harddisk in the guest operating means there needs to be a 2GB file on the host.

Now, are you saying that you have use something like a 2GB harddisk in the guest OS but the size of the .IMG file blows beyond these 2GB to 10GB? Then this would be a severe problem indeed.

But if you say you have a 10GB harddisk with a .IMG file that somehow has been truncated (by cutting off the zero bytes at the end) and then by using it in DOSBox you see it grow to the full 10GB that might just be expected behavior. If the operating system wants to read or write near the end of the partition, DOSBox needs to make sure that the 'physical position' requested by the guest system exists in the .IMG file.

So I need to confirm first, for that case where it increased by 10GB or so, what is the size of that harddisk as reported by the guest operating system? It would be best to not just look at the D: partition but the full harddisk size by pressing Shut Down -> Restart in MS-DOS Mode then running fdisk and opening the Change current fixed disk drive sub-menu.

[PythonBlue]

Yes, I have figured the part out about compressed img's for myself as well. That being said, the experiments I was referring to did not make use of any compression that I know of, not even zip files.

Unfortunately, the 2GB-expanding-to-10GB scenario is exactly what I'm referring to as reported by the host operating system, and also coincidental because the usual D drive choice was roughly originally that size (the D drive one was not created through the Pure templates, but it did conform to a geometry that IMGMOUNT would accept. The C drive was variable sizes depending on the experiment, but I do vividly recall 1 GB for that on some of them). As for what the guest would report for capacity, I admittedly was so alarmed by the bug that I was quick to delete the resulting img's and start over before I could even verify their capacities in the guest, though I can confirm that they could still read and write fine. If it happens again, rest assured, I will be sure to follow your recommended diagnostic procedure.

[PythonBlue]

Well, some silver lining: after reluctant resuming of experimentation with multiple hard drives again, it hasn't reoccured yet. There's also a chance the error was related to using IMGMOUNT on the same image for different working drives, though I'm uncertain why that would be because I always re-mounted one of them in my tests to something else via the DosBox Pure menu before booting.