Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The thinking behind the 32GB Windows Format limit on FAT32

theregister.com

Post reply on HN
Print view View original

51–60 of 75 posts

Re: The thinking behind the 32GB Windows Format limit on FAT32

#51

Post by pantalaimon »

MrDOS wrote: post #46
avidphantasm wrote: post #41

Hopefully exFAT implementations will get more robust. At least with the macOS implementation, it has always been prone to reporting corruption when devices are not ejected properly. I can usually fix it by running check disk or whatever on Windows, but sometimes not.

I've had more filesystem corruption trouble with exFAT on Linux than with any other filesystem, ever, including Btrfs. Really crossing my fingers and hoping for the quality of the Samsung driver in Linux 5.7. It's going to be great to have an option for high-capacity, cross-platform read/write storage. The day I never have to use NTFS-3G again cannot come too soon.

> The day I never have to use NTFS-3G again cannot come too soon.

That day might be soon

https://lkml.org/lkml/2020/12/31/126

Re: The thinking behind the 32GB Windows Format limit on FAT32

#52

Post by kasabali »

MrDOS wrote: post #44
grenoire wrote: post #40

Earlier quoted context omitted.

Huh, I thought exFAT was much older, not 2019.

It is – it dates back to 2006. But before 2019, the spec was proprietary and patent-encumbered. And the Linux kernel didn't include a good driver for it until 5.7, released in May of last year[0]. [0]: https://kernelnewbies.org/Linux_5.7#New_exFAT_file_system

It is still patent encumbered. MS just promised to not give trouble for it being in the Linux kernel.

Re: The thinking behind the 32GB Windows Format limit on FAT32

#53

Post by kasabali »

MrDOS wrote: post #46
avidphantasm wrote: post #41

Hopefully exFAT implementations will get more robust. At least with the macOS implementation, it has always been prone to reporting corruption when devices are not ejected properly. I can usually fix it by running check disk or whatever on Windows, but sometimes not.

I've had more filesystem corruption trouble with exFAT on Linux than with any other filesystem, ever, including Btrfs. Really crossing my fingers and hoping for the quality of the Samsung driver in Linux 5.7. It's going to be great to have an option for high-capacity, cross-platform read/write storage. The day I never have to use NTFS-3G again cannot come too soon.

Were you using the FUSE driver?

Re: The thinking behind the 32GB Windows Format limit on FAT32

#54

Post by MrDOS »

kasabali wrote: post #52
MrDOS wrote: post #44

Earlier quoted context omitted.

It is – it dates back to 2006. But before 2019, the spec was proprietary and patent-encumbered. And the Linux kernel didn't include a good driver for it until 5.7, released in May of last year[0]. [0]: https://kernelnewbies.org/Linux_5.7#New_exFAT_file_system

It is still patent encumbered. MS just promised to not give trouble for it being in the Linux kernel.

Right – that's what I meant, but I didn't communicate it clearly. Thanks for clarifying.

Re: The thinking behind the 32GB Windows Format limit on FAT32

#55

Post by kasabali »

hocuspocus wrote: post #11

If my memory serves well, when 40+ GB HDDs started being common, you were either using Windows 2000 and NTFS already, or it was probably a good practice to have several partitions, given the overall unreliability of Windows 9x and the not so infrequent clean reinstallations. And then came Windows XP and the issue was moot. It's a bit of a shame Microsoft didn't push and open up exFAT earlier and allowed FAT32 to beco…

> It's a bit of a shame Microsoft didn't push and open up exFAT earlier and allowed FAT32 to become an issue again, only with removable flash drives and memory cards this time

Erm, because that was the idea? SDXC is a big racket and Microsoft has been collecting patent fees from any kind of consumer device that's capable of reading memory cards thanks to the filesystem requirements in the standard.

Re: The thinking behind the 32GB Windows Format limit on FAT32

#56

Post by MrDOS »

pantalaimon wrote: post #51
MrDOS wrote: post #46

Earlier quoted context omitted.

I've had more filesystem corruption trouble with exFAT on Linux than with any other filesystem, ever, including Btrfs. Really crossing my fingers and hoping for the quality of the Samsung driver in Linux 5.7. It's going to be great to have an option for high-capacity, cross-platform read/write storage. The day I never have to use NTFS-3G again cannot come too soon.

> The day I never have to use NTFS-3G again cannot come too soon. That day might be soon https://lkml.org/lkml/2020/12/31/126

I know everyone talks about 2020 having felt like a long year, but I had totally forgotten that Paragon had started trying to submit that back in August[0]. I'm really glad to see this is progressing. What a monumental set of changes. This won't change the NTFS situation on macOS, of course but even in a post-exFAT world, NTFS will remain a relevant concern for Linux/Windows dual-booting, and I'd love to see this get merged.

[0]: https://lore.kernel.org/linux-fsdevel/2911ac5cd20b46e397be50...

Re: The thinking behind the 32GB Windows Format limit on FAT32

#57

Post by MrDOS »

kasabali wrote: post #53
MrDOS wrote: post #46

Earlier quoted context omitted.

I've had more filesystem corruption trouble with exFAT on Linux than with any other filesystem, ever, including Btrfs. Really crossing my fingers and hoping for the quality of the Samsung driver in Linux 5.7. It's going to be great to have an option for high-capacity, cross-platform read/write storage. The day I never have to use NTFS-3G again cannot come too soon.

Were you using the FUSE driver?

That's a great question. I kind of skirted around indicating one way or the other in my parent post because I've forgotten. My troubles were as recent as the beginning of 2020, but I encountered them on a Raspbian machine, so Lord knows what kernel version it was running at the time. Probably pre-5.4, in which case, yes, it would've been the FUSE driver.

Re: The thinking behind the 32GB Windows Format limit on FAT32

#58

Post by Abishek_Muthian »

m000 wrote: post #3

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. [1] https://en.wikipedia.org/wiki/ExFAT [2] https://en.wikipedia.org/wiki/Open_Invention_Network

Much before MS did that, macOS had builtin exFAT support presumably licensed from MS, Paragon had exFAT support for android for a one time fee which works with other file manager apps(also licensed from MS), On Linux Exfat-utils enabled support for exFAT(open-source implementation).

Has there been any changes to these since MS has opened the license to exFAT?

Re: The thinking behind the 32GB Windows Format limit on FAT32

#59

Post by numpad0 »

bilekas wrote: post #16
gruez wrote: post #6

Earlier quoted context omitted.

>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.

I would imagine if embedded devices are being assembled and configured with filesize concerns, then exFAT would be the natural implementation they would opt for. Or do you mean updating/transitioning legacy embedded? 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 b…

I believe the implication is SD card/USB drive support on microcontrollers without an OS.

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.

Re: The thinking behind the 32GB Windows Format limit on FAT32

#60

Post by adrian_b »

fuzzfactor wrote: post #45
m000 wrote: post #3

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. [1] https://en.wikipedia.org/wiki/ExFAT [2] https://en.wikipedia.org/wiki/Open_Invention_Network

The patents on FAT32 are now fully expired, including the final lingering LongFileName one. 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 main use for FAT32 and exFAT is to transfer files between different operating systems or between a computer and some dedicated device, e.g. a photographic camera.

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.

Post reply on HN