#10 Using -p with a loopback device under dos causes the number of hidden sectors to be the max long

[i30817]

If you have linux i was trying to code this script: https://gist.github.com/i30817/f9705d8e2977a7e1a4ce17530732c8f8

To create or resize images for dosbox to boot. Anyway on resizing a image with windows 95 already i decided i needed ms-sys and i tried it. It could write the VBR to the filesystem if i used it on the mkdosfs output file directly with -f but it couldn't boot. So i decided to try the -p flag, which requires a 'real filesystem' so i placed it after parted and mounted. Unfortunately this requires sudo to write to the partition so one thing i'd ask would be command line switches to bypass the need for ioctls so i could write to the file directly without sudo.

Disregarding that, the code 'unsigned long partition_start_sector(FILE *fp)' at 'identify.c' appears to have a bug when used with the loopback device like that, and shows that it wrote max long 'hidden sectors'.

With the script, the dependencies and ms-sys cloned and built into the same dir as the script in amd64, given this exec (remove a.img later):
./mkwin9xfs -f 35MB a.img

it outputs as part of the output 'Start sector 94378491969707 (nr of hidden sectors) successfully written to /dev/loop2p1'

I leave it to you to find the bug.

[i30817]

Actualy it's not the max long but the uninitialized value of sGeometry.start. Probably because it's a loop device not a real drive, so the ioctls are returning weird values. I tried to print it and ' iRes1 = ioctl(iFd, BLKGETSIZE, &lSectors);' makes iRes1 0 and ' iRes2 = ioctl(iFd, HDIO_GETGEO, &sGeometry);' makes iRes2 -1

then
if(! (iRes1 && iRes2) )
return sGeometry.start;

the inner is false because of iRes2, so it returns the uninit value. This seems wrong.

Could we get a command line switch to provide this 'sGeometryStart'? Could it double as the 'offset' to operate on files without sudo if the given file is a real file?

Also why is the -p command seemingly limited to FAT32?

[Henrik Carlqvist]

Sorry, the things you are asking for are attributes of real physical disks like their number of heads. To find out those attributes you really need to use ioctl, there is no other way to find out and an image file does not have any such real physical attributes. If you really know what you are doing you can manually set the number of heads using the -H switch, but again, the rest of -p assumes that you are working on a physical disk. My advice to you is to work on your image file from within some virtual environment like qemu, that will make your image file look like a real physical disk. Unless you still really think this is a bug and are willing to produce a working patch for the bug yourself I am going to close this bug report with a "closed-won't-fix".

[Henrik Carlqvist]

Sorry, the things you are asking for are attributes of real physical disks like their number of heads. To find out those attributes you really need to use ioctl, there is no other way to find out and an image file does not have any such real physical attributes. If you really know what you are doing you can manually set the number of heads using the -H switch, but again, the rest of -p assumes that you are working on a physical disk. My advice to you is to work on your image file from within some virtual environment like qemu.