FAT32 might have its limitations but it is at least small and simple enough to be implemented in a few K of boot code. That's the reason I still use it with FPGA projects.
Do you have details on what makes exFAT less safe than FAT32? To my understanding they should be pretty similar, at least. Obviously neither is journaling and might need the occasional fsck.
> The standard exFAT implementation is not journaled and only uses a single file allocation table and free-space map. FAT file systems instead used alternating tables, as this allowed recovery of the file system if the media was ejected during a write (which occurs frequently in practice with removable media).
ExFAT is also used by fake USB drives which claim to be much larger than they really are.
> FAT file systems instead used alternating tables, as this allowed recovery of the file system if the media was ejected during a write (which occurs frequently in practice with removable media).
This doesn't seem right to me (and the article also does not quote any source for this assertion). As far as I know, the secondary FAT is a leftover from days where block storage devices didn't have firmware-level bad block remapping, not really a consistency mechanism.
It certainly doesn't prevent inconsistencies between files/directories and the FAT, and you still need an fsck-like process to clean these up that traverses the file system when mounting a non-clean ejected FAT.
> ExFAT is also used by fake USB drives which claim to be much larger than they really are.
USB drives are block devices, and if they maliciously trick the host into assuming larger size than they actually are, that's hardly the filesystem's fault, is it?
FAT32 might have its limitations but it is at least small and simple enough to be implemented in a few K of boot code. That's the reason I still use it with FPGA projects.