Device makers that do support exFAT have to pay Microsoft for every sale. It's why for example the Nintendo Switch enables exFAT as a "system update"; that way Nintendo doesn't have to pay Microsoft for every single switch sold, only the ones that are actually using exFAT for external storage.
I think the last of those patents will expire by 2027? You'll probably see an uptick in exFAT use by then.
(Also that’s still a floppy-grade filesystem, no journalling or anything.)
And then there is the thing with the long file names extensions because FAT originally could only do 8.3 names.
I know because i tried to write a FAT driver myself.
NTFS? Won't work on Mac
HFS+? Won't work on Windows
EXT4? Won't work on Mac or Windows
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.
> 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.
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?
> Would wish the industry could agree on using something more modern and reliable.
There’s no techical reason why we can’t use NTFS on Macs or APFS on Windows, if the industry was willing work towards that goal together.
As I heard from an anonymous friend at Apple, macOS was weeks away from announcing an official transition to zfs and then oracle bought sun.
Presumably, as a courtesy Apple asked oracle to confirm it was free to use zfs (since it was published under a permissive license). Oracle demanded money anyway. Apple blinked - not wanting to get sued by oracle. And the rest is history. A couple years later Apple wrote their own proprietary zfs like filesystem called APFS that has many similar features. And that has, to my knowledge, not been opensourced.
(It does have very detailed documentation though. Holy cow - 180 pages. https://developer.apple.com/support/downloads/Apple-File-Sys... )
macOS might have switched to something more modern a bit sooner than they did, but I wouldn’t be surprised if they hadn’t switched to APFS anyway after a while. Being able to independently drive your non-detachable-storage FS spec is a pretty big advantage as an OS vendor.
Using an opensource filesystem like zfs doesn’t mean you aren’t in charge of your own destiny. Apple has skilled systems engineers. They could easily have made custom extensions and changes to zfs if they saw fit.