Back to home page

DOS ain't dead

Forum index page

Log in | Register

Search:  
Back to the forum
Board view  Mix view

FAT32 drive on GPT (Miscellaneous)

posted by ecm Homepage E-mail, Düsseldorf, Germany, 02.09.2023, 14:07

> The actual FAT type "is determined solely by the count of clusters on
> the volume", and not by the partition type id, according to the
> Microsoft FAT specification [1], page 14.
>
>
> [1]
> https://academy.cba.mit.edu/classes/networking_communications/SD/FAT.pdf
This is what they claim in the specifications, but most drivers actually support "small FAT32" (with less than 65_536 data clusters) and only distinguish FAT32 from FAT12-or-FAT16 by testing whether the 16-bit Sectors per FAT field is zero. (The Amount of Root Entries field is also zero on FAT32, nonzero on FAT12-or-FAT16. It is uncertain what would happen if one of these fields is zero and the other nonzero.)

I also tested that EDR-DOS supports small FAT32, in https://www.bttr-software.de/forum/forum_entry.php?id=20608

I did quote some mtools discussion on this in https://github.com/dosemu2/fdpp/pull/202#issuecomment-1264597486 :

mtools just had this edge case fixed. The truth is that the word (16-bit) "sectors per FAT" field being zero indicates using both the larger EBPB and FAT32. It doesn't really matter how many clusters there are, you can create a FAT32 file system with less than 64 Ki clusters. That seems to be what most drivers, including Microsoft's, actually do.

Quoting from the mailing list for mtools: https://lists.gnu.org/archive/html/info-mtools/2022-09/msg00003.html

> >>> 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://...ba512-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.

---
l

Post reply
 

Complete thread:

Back to the forum
Board view  Mix view
22049 Postings in 2034 Threads, 396 registered users, 30 users online (0 registered, 30 guests)
DOS ain't dead | Admin contact
RSS Feed
powered by my little forum