TIL: In 2019, Microsoft released the exFAT [1] specs to a large group of vendors [2], including prominent Linux vendors. I.e. exFAT should now be preferred over FAT/NTFS for media used across different operating systems.
Therefore FAT32 will remain preferred until the patents expire on exFAT, even though the specification for exFAT has been released, things like that have proven to be not good enough until after the patents expire.
The purpose of exFAT appears mainly to be an attempt to foist a new encumbered filesystem on developers now that the first mainstream Microsoft filesystem is in the public domain.
We will know when Microsoft has reduced their anti-user stance on filesystems after they have released very detailed full NTFS specifications in the most useful way possible.
Also I have the greatest respect for Dave, and like he mentioned he was only doing the UI not the bitmoving of the actual Format process.
Those who were developing the NT version of FAT32 formatting failed in much more serious ways where Dave did not.
The inconsistency compared to FAT32 formatted by W9x is actually intolerable.
Best reliability still requires booting to the DOS from W98SE to properly format FAT32.
They are not useful for anything else except memory cards, USB sticks and external SSDs.
Unfortunately, nowadays it is frequently necessary to copy files larger than 4 GB. When using FAT32, you cannot do that without splitting the file and concatenating the parts at destination. That wastes time and it is annoying and sometimes it may be even impossible, when the destination lacks a concatenation program or an archiver that can deal with split archives.
After Microsoft released it, now exFAT is supported in the Linux kernel. Because exFAT is also supported by all commercial operating systems, it is now the best way for file transfer.
It does not matter any more if there are still valid patents for exFAT.
Would you care to elaborate for why that is? Would anyone else with knowledge about the patent system and any possible risks imposed by it also like to do so?
IANAL - so there's likely some caveats (you probably can't just use the exFAT name unless certain qualifications are met, just like you can't use Firefox's trademarks willy-nilly), but that should be good enough for just about anyone. Including paranoid OSS peeps like me :)
0: https://cloudblogs.microsoft.com/opensource/2019/08/28/exfat...
I don't know how the release to Open Invention Network affects things, though.
No its inclusion in Linux was the result of a decision by Microsoft, not a granting of an open license. Any other implementation still has to apply for a license:
"For customers wanting only a patent license, you can contact us to learn more about the exFAT licensing program and request a pricing proposal."
To put it bluntly, if Microsoft's guarantees are good enough for Linus so as to merge the driver in the Linux mainline, they're good enough for me too.
But for a fun fact, if you see many embedded systems that say they can only support an SD card up to 32 GB, it is a soft limitation due to the fact that media over 32 GB are pre-formatted to exFAT (and the system lacks support for exFAT). FAT32 can go up to 2 TB. So I have found that reformatting a larger media back to FAT32 makes it recognizable to that system with all of the storage space.
There might also be the issue of the card reading hardware only supprting SDHC instead of SDXC (or SDUC).
My old laptop has Ricoh SDHC card reader. Windows can't read 64GB SD cards (properly formatted with exFAT according to the standard) on it because it's using the proprietary Ricoh driver.
On Linux it works just fine because it's using the generic SD card reader driver which supports SDXC.
You seem to be very optimistic about how fast these get implemented into embedded devices.
OTOH, I do have the Windows logo on my steering wheel, and somewhere inside the car there's a Windows CE system installed (it doesn't have a multi-color LCD screen and interacts using speech recognition, so it's not really obvious).
The spec doesn't mention backwards compat, but does mention as a goal
>Retain the simplicity of FAT-based file systems.
I would like to test out if an input embed system is exFAT compat. And what might be required to update.
SD under 32GB uses FAT32 so you can’t drop supports, and FAT32 stack is often already pushing the maximum ROM size, so no room is left for a novel filesystem. Lots of developers aren’t themselves proficient at writing filesystem code as well, and there aren’t as many copy-pastable exFAT implementations as there are for FAT32.
So unless they know what they’re doing and unless it’s critical to their product, the majority won’t easily move onto exFAT.
As for the use within the device “firmware”, the user defined program is usually just a giant baremetal a.out in the middle of the ROM at a specified address, so no FS is involved there.
I have had issues with ntfs getting corrupted and losing file both in mac and linux at times so there's that risk with implementation too.
Has there been any changes to these since MS has opened the license to exFAT?
Therefore, if you have a recent Linux kernel, you no longer need to install a user-mode driver for exFAT and the kernel driver has better performance.
Regarding Linux, exfat-utils only provided limited functionality. The kernel mainline lacked a native exFAT driver. Mounting exFAT volumes was possible only through FUSE (with all its shortcomings).
[0]: https://kernelnewbies.org/Linux_5.7#New_exFAT_file_system