info-mtools
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Info-mtools] Incorrect assignment of partition type in mformat/mpar


From: Alain Knaff
Subject: Re: [Info-mtools] Incorrect assignment of partition type in mformat/mpartition
Date: Mon, 24 Sep 2018 07:32:45 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1


On 24/09/18 00:05, Pali Rohár wrote:
> On Sunday 23 September 2018 23:07:53 Alain Knaff wrote:
[...]
>> There is only one difference which struck my eye: in order to chose
>> between 0x06 and 0x0e you check whether the partition is entirely below
>> the 1024 cylinder mark. However, wikipedia claims that the cutoff should
>> be at 8GB (or rather 16 G sectors). The Microsoft source cited by
>> wikipedia
>> (https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-2000-server/cc977219(v=technet.10)
>> claims a cut-off of 4GB...
> 
> IIRC Microsoft implementations support FAT16 filesystem only up to the
> 4GB size. Therefore I guess this is why they specified 4GB limit also
> for 0x06 MBR id which belongs to FAT16.
> 
>> So, now I'm puzzled which of the 3 is correct. Or maybe you still have
>> other supporting documentations which you'd like to share? In any case,
>> 8GB does indeed roughly correspond to 1024 cylinders if 63 sectors and
>> 255 heads are used (which would indeed be picked by LBA assyst for 8GB)
> 
> I do not have any "official" documentation. But 1024 cylinders is for
> sure upper limit. When you are using CHS geometry, then you store 10 bits
> for cylinders into MBR partition table. Therefore every CHS partition
> must end at 1024th cylinder. And because 0x06 MBR type indicates usage
> of CHS, maximal theoretical size is of 0x06 partition in number of
> sectors is: sectors * heads * 1024.
> 
> I guess that people started referring to 8 GB, just because it is "near"
> 63*255*1024 sectors (=~ 8032.5 MB =~ 7.84 GB).
> 
> Number 8 GB itself does not make much sense -- when all addressing was
> done by CHS and by DOS interrupts which took tuple (C, H, S).

I see. So I'd go for a combined condition: track must be less than 1024,
_and_ size must be less than 4GB

> 
>> In the meantime, I re-arranged the tests to make it easier to understand
>> what is going on:
> 
> That is not exactly same code.
> 
> You forgot for case when FAT12 partition is bigger then 4096 sectors. In
> that case 0x06 should be used too. Reason is that 0x01 is supported by
> old DOS versions only for FAT12 partitions with less then 4096 sectors.
> In my original patch this case was included too.

Indeed, I changed 32680 to 4096, as this was what the Microsoft
documentation at
https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-2000-server/cc977219(v=technet.10)
seems to say:

0x01    FAT12 primary partition or logical drive (fewer than 32,680
        sectors in the volume)

Do you maybe have some "official" source for the 4096 sectors? (I am
aware that 4096 was what I had in 4.0.18...)

In any case, as far as I know, these partition type bytes are "for
information only": even DOS/Windows itself actually checks the partition
itself to see whether its FAT12, 16, 16B or 32. The partition byte is
only checked to see whether its one of the FAT* partition types (rather
than "extended" or another OS such as Linux).

Regards,

Alain



reply via email to

[Prev in Thread] Current Thread [Next in Thread]