undefined

points

[-]

Yes, I think that's a fair assessment, although the fractal of stupid runs deep in FAT32: a separate 5-bit field for seconds within a minute? Separate fixed-width fields for filename and extension? A 4 GiB file size limit?

But, although FAT32 does indeed have the virtue of relative simplicity, that's no excuse for VFAT.

by doublepg2318 hours ago|

parent|

[-]

I might be unfamiliar with the terms - is there a distinction between FAT32 and VFAT?

by duskwuff17 hours ago|

parent|

[-]

VFAT is the way that some operating systems implement long filenames in FAT - PROGRA~1 and whatnot. It's pretty messy.

by fredoralive7 hours ago|

parent|

prev|

[-]

Windows 95 introduced long filenames to FAT, and implements the file system in the VFAT.VXD driver. “VFAT” is thus sometimes thus shorthand for FAT with “Windows style long filenames”. It can be applied to all variants of FAT, such as FAT16 and FAT32.

FAT32 is a variant of FAT introduced in the mid 90s with Windows 95 OSR2 that better supports large hard drives (beyond size limits, cluster sizes were getting too large on FAT16 drives etc.).

by JdeBP13 hours ago|

parent|

prev|

[-]

Not really, no. Linux regards various ways of looking at the same on-disc filesystem format as distinct filesystem types: msdos, umsdos, vfat. Old Microsoft doco from the 1990s that is still lying around explains things in the way that they historically progressed rather than structurally, describing VFAT as an extension of FAT32.

The reality, certainly in respect of the headlined subject, is that the bitness of the FAT and the style of the root directory (fixed location or variable length) are the only meaningful variants. In 2026, no-one aims not to support long filenames on FAT, and EFI understands them natively. EFI copes with all three bitnesses. And it does the conventional thing of variable length root directory on 32-bit and fixed-length root directory on 16-bit and 12-bit.

FAT is a very poor filesystem format, and no, it's not a minimum filesystem format if one is writing one's own operating system. It's a lazy filesystem format, inasmuch as the cross-development tooling for it exists. But if one were writing a minimum filesystem for one's own operating system, one could start from much better places. FAT is not minimal by any reasonable definition even if one is not writing one's own operating system, and requires an awful lot of hoops to be jumped through that are only there because one is being compatible with the cross-development tooling, several decades of historical changes, and whatnot.

One could use the original UFS, for example. LEAN exists. Over 20 years ago, I invented HPFS2.

* https://jdebp.uk/Proposals/hpfs2.html

by kragen13 hours ago|

parent|

[-]

HPFS2 looks appealing. Did you implement it? And what were the design blunders in LEAN you decided not to go into in the footnote?

Given that normally UEFI only needs to read the filesystem, not write it, I think a more appropriate filesystem might be something like ZIP.