> It's a real pity everyone can't agree on a standard to replace FAT32. :(
Every OS in the universe supports UDF now, and its the only real ubiquitous non-proprietary filesystem. I use it on all external storage that I cannot guarantee will be touching Linux machines exclusively.
> surely it would be extremely beneficial to have at least 1 open source filesystem that has good support across all platforms
The comedy of this is that there are actually plenty of FSes common to all three of these OSes, they're just not considered "modern"; FAT32 is still the most commonly used FS for interop, even as it shows its age with poor support for very large files (2+GB) and file systems, but you also have ISO(9660) and (the best answer we currently have) UDF supported by all three OSes natively and openly without patents or other licensing restrictions. The latter two are not commonly used as read/write filesystems, but have zero inherent restrictions on being able to be used in such a way.
However, the problem has been largely supplanted by having a fast and well-functioning network and people moving to "The Cloud" for, well, everything. It's hard to know how much of the Great Cloud Migration is caused by these kinds of intentionally engineered interoperability fails, especially the monumentally stupid exFAT patent... It's interesting to ponder given the people likely to complain the most about filesystems today are people who want to move large files (4+GB) between OSes without anguish, where the network is still just too slow to handle the task well.
> It's 2017, and the ONLY filesystem that will seamlessly work with macOS, Windows and Linux at the same time is FAT, a filesystem which is almost 40 years old.
Universal Disk Format? [1]
ExFAT can also be used on all currently supported versions of Windows & macOS and added to Linux very easily via a package manager.
You could argue there isn't any need for a cross-platform filesystem these days. It's often easier to simply transfer files over Ethernet, Wi-Fi or even the Internet.
>TIL: In 2019, Microsoft released the exFAT [1] specs [...] I.e. exFAT should now be preferred over FAT/NTFS for media used across different operating systems.
You seem to be very optimistic about how fast these get implemented into embedded devices.
>Finally, we get a non-journaled semi-cross-platform filesystem. fat32 just wasn't cutting it... /s
Hope you never had to store files larger than 4GB otherwise FAT32 would not work for you. (Before you respond with "that's what archive files / files splitting are for", not every device that takes files on an SD card and supports FAT32 has a way to join files on the fly/a way to read archived files.)
> They would also have to drop support for FAT32 as you pointed out.
This is a little dubious. When you load a FAT driver on a *nix system, you get the limitations of FAT. Likewise there are lots of fancy filesystem APIs in Windows that fail on a FAT volume and work on NTFS.
That said, there are a lot of quirky NTFS behaviors that are ultimately rooted in FAT. I used to get frustrated by a lot of them, then I started writing a FAT driver just for fun ... and it made sense. All the goofy things about naming start to make sense if the direntry "is your inode" and the extra space in the name is padded with spaces...
> I've never seen a motherboard supporting anything else than FAT for an UEFI partition.
I've seen exactly one model line, that does support NTFS in UEFI: Intel NUCs. It was quite nice, but nobody preparing boot media can rely on the availability, as the only mandatory filesystem is FAT32.
> Is it really necessary to keep dragging FAT along?
Anything involving embedded and without deep pockets has no other option, FAT (sadly) still is the least common denominator. Some speak ExFAT, but not sure how good the tooling support is outside of Microsoft, and there are still patent concerns.
> exFAT is probably better in terms of cross platform compatibility and addresses a lot of the limitations of FAT while remaining portable.
Still it is a shame that we're kept back literally decades when it comes to file exchange due to corporate culture polluting every corner of IT. Ensuring file export options plus file formats full documentation, should be among the most important requirements any software should satisfy to be even considered for professional use.
Straight from their FAQ:
We see emFile customers asking for solutions for bigger files. Implementing exFAT is not an option for us, as it is patent encumbered. SEGGER would need Microsoft's permission to implement and offer it, and our customers need to deal with Microsoft again to be able to use it in their products. This can be time-consuming and also expensive. We feel there should be a free alternative. The more popular BigFAT becomes, the better.
I guess using anything but FAT would make it hard for their developer base.
No, but FAT32 does. Exfat, on the other hand has a file size limit of 16 exibibytes. That, combined with exfat's cross-platform mounting (NTFS has a lot of limitations in this regard) makes it a superior formatting system for flash based offline file transfer.
>Since Apple and Microsoft categorically refuse to implement any of the many featureful existing filesystems, one is stuck with archaic NTFS (with no file permissions) or FAT (with less than 4gb files) to keep data.
xFAT which I already mentioned is supported and doesn't have a 4GB limitation. You can have up to 128 pebibytes (which should be enough for everybody: that's ~144 petabytes).
Afaik all operating systems read and write UDF formatted sticks and UDF is quite simple as well, and has none of the limitations FAT has. Also no patents.
Every OS in the universe supports UDF now, and its the only real ubiquitous non-proprietary filesystem. I use it on all external storage that I cannot guarantee will be touching Linux machines exclusively.
reply