Re: [Info-mtools] [BUG] mcopy unable to copy to small FAT32 image starting v4.0.32

[Alain Knaff]

Hi Pali, hi all,

On 17/09/2022 11:49, Pali Rohár wrote:
> On Saturday 17 September 2022 01:24:03 Alexander Bazarov wrote:
[...]
>>> Actually, according to Microsoft's specification, number of FAT bits of
>>> an existing filesystem is SOLELY determined by the number of clusters.
>>> This applies to all *three* bit numbers: 12/16/32

Yes, the (in)famous fatgen103.pdf document, retired from Microsoft's own
site, but still available at
https://web.archive.org/web/20210723100623/http://download.microsoft.com/download/1/6/1/161ba512-40e2-4cc9-843a-923143f3456c/fatgen103.doc

It sternly says at page 14:

"It is really quite simple how this works. The FAT type— one of FAT12,
FAT16, or FAT32—is determined by the count of clusters on the volume
and nothing else."

But see below...:

[...]
> But as Alain pointed Microsoft FAT implementation (fastfat.sys) for
> FAT32 detection does not use number of clusters, but rather explicit
> marking of FAT32. Same behavior has Linux kernel implementation
> (msdos.ko and vfat.ko) and same in dosfstools project. Hence this
> non-standard FAT32 can be still created by mkfs.fat.

Actually, what I meant in my previous mail was that *everything else*
that is referred to in the FAT32 extended boot block (root directory
location, etc.) would depend on this explicit marking
(fatLen/bigFatLen), but not the number of FAT bits themselves.

However, your remark got me thinking, and so I tried it out on a Windows
10 VM.

... and lo and behold: the mere presence of a FAT32 extended boot block
(as signaled by fat_len being 0) was enough to make it use 32 fat bits,
even if the number of clusters was too low for FAT32.


Sorry for having been to easily misled by an assertive, but nonfactual,
Microsoft statement.

Given this finding, I'll shortly make a new mtools release that will
consider presence of FAT32 extended boot block as well for picking
appropriate number of FAT bits.

Regards,

Alain