Re: [Info-mtools] Wrong default "physical drive id" produced by Mformat on hard disk

[Alain Knaff]

Hi,

On 23/02/2023 13:52, Nutchanon Wetchasit wrote:
[...]
> When I compared Minfo output of this installer-formatted partition
> against Mformat-formatted one; among the lines in unified diff output,
> I spotted this:
> 
>> -physical drive id: 0x80
>> +physical drive id: 0x0
> 
> ^ The first line was from Windows installer-formatted partition,
>   while the second line was from Mformat-formatted partition
> 
> I know full well how this field was used when the volume in question
> was a boot volume (i.e. int13h drive number to use for accessing the disk);
> so it not being 0x80 "first hard disk" made it a prime suspect.
> 
> I have double-checked relevant Info section and Unix manual page,
> and it become apparent that Mformat did not seem to provide
> any command line option to set this field manually either.

I now added a -b flag to mformat in release 4.0.43, as per your
suggestion below.

[...]
> The issue is, Mformat does not seem to put a sane default 0x80 value
> in this "physical drive id" field even that it did seem to correctly guess
> that the volume is on a hard disk as opposed to floppy-like media
> (if a correct 0xF8 "fixed disk" media descriptor byte produced
> should be any indication).

I also now changed mformat to use 0x80 for the physdrive if media
descriptor is 0xf8 (whether calculated, or specified as such). Of
course, this determination can still be overridden with -b

[...]
> [1] I'm not too sure what name to suggest for this new option.
>     I was originally about to suggest `-b` (Bios disk number);
>     but Mformat's section in Texinfo manual already said that MS-DOS
>     `format` had `/b` option (for quite a long time [2]),
>     which Mformat doesn't implement-- so using `-b` might be misleading.
>     `-B` is also already used.

-b was indeed there, but only as an "unsupported" option giving an error
message. So, no harm replacing it with a functional one.

[...]
>     As for the radix of option's argument, it could probably use
>     the same rule as the existing `-m` (Media descriptor) option. [3]

Exactly.

[...]
> [3] A loophole in the documentation of `-m` option of this Mformat version
>     (in both Texinfo and Unix manual page) is that it doesn't seem to say
>     which number base (decimal, hexadecimal, prefix-select, suffix-select)
>     that user is supposed to specify the value in.

It uses C's strtol or strtoul function, with 0 base, which means use the
prefix to decide the base:

- starts with non-zero digit => base 10
- starts with 0x => base 16
- starts with 0 => base 8

(if the number happens to a lone 0, base doesn't matter, as 0 is 0 in
both base 8 and 10 :-) )

on top of this, mtools implements a size suffix, for those numbers that
represent sizes (K, M, G or s for 512 byte sectors)

>     
>     It seems to accept decimal number by default; but heuristically switch
>     to hexadecimal when it found letter in the range of `a`-`f`
>     and/or `A`-`F` in the value.

Nope, it uses the prefix 0x to switch to hex. Letters alone are not
enough to trigger the switch. Instead, only the initial part comprised
of digits is parsed, and it stops at first letter.

>     
>     C-style radix prefix seems to be accepted as well:
>     "0" prefix (not "0o" prefix and not "o" suffix) for octal,
>     and "0x" prefix (not "h" suffix) for hexadecimal; which of course
>     no prefix/suffix available for explicitly denoting decimal
>     ("0d" prefix and and "d" suffix triggered heuristic switch
>     to hexadecimal), binary is not accepted ("0b" prefix and "b" suffix
>     would trigger heuristic switch to hexadecimal).
> 

man strtoul

Regards,

Alain