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?
UDF should have been a viable alternative, but as I’ve said elsewhere it only works for disks smaller than 2T bytes with 512-byte sectors, and the Windows behaviour around it seems strange.
Installable is nice, but preinstalled is the only thing that really matters for pluggable storage devices (USB drives, DSLRs that don't use MTP/PTP etc).
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.
I think it’s unrealistic to think that Microsoft or any embedded device vendor would have ever implemented ZFS, regardless of the patent situation.
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.
Well, according to my source, it would have actually happened if not for oracle. These decisions really come down to the people involved. I’m sure some people, given that choice, would never consider zfs. But some clearly would - and did.
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.
ZFS has a big footprint, so it could be of a problem for integrated solutions, like digital cameras needing to save images to a flash-card without having a lot of hardware power.
> 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.