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

[Pali Rohár]

On Monday 24 September 2018 07:32:45 Alain Knaff wrote:
> 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

Mhm... No I remember that I read some MS documentation (do not have link
right now) that limit 4GB is for 512 sectors disks. And Windows NT for
disks with larger sector sizes supports FAT16 volumes also larger then
4GB. I guess this is just because all addressing in CHS and also in LBA
stored in MBR partition table is in "sectors" unit.

Therefore limit specified in bytes, independently of the sector size is
not correct too.

> > 
> >> 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).

I just know that Linux ignores MBR ids (exceptions are ids for
extended/logical partitions) and Windows NT/XP uses them just for
running detection if partition should have assigned driver letter or
not. IIRC Windows 98 need to have correct MBR id to work properly, also
any non-FAT partition with some FAT* mbr id was visible, but was empty
and read-only.

I do not know right now what MS-DOS did when MBR id did not match FAT*
variant. But I read somewhere that older versions of DOS supported FAT12
only on disks with 4096 sectors. And to prevent having that partition
visible on those systems it was a good idea to assign different MBR id
as 0x1 as those systems ignored them.

But do not have exact references. If you need them I could try find
them, but it would not be now.

> Regards,
> 
> Alain
> 

-- 
Pali Rohár
address@hidden