The Initial exFAT Driver Queued For Introduction With The Linux 5.4 Kernel

[dwagner]

If it corrupts my drives (possible due to the poor code quality), I consider it to provide "no support at all".

Actually, corruption of exFAT filesystems was exactly what I experienced when I once tried the "exfat-nofuse" in-kernel implementation. When writing directory trees with many files, suddenly random garbage appeared in the metadata.
Switched back to only use the FUSE-based implementation, which is considerably slower, but at least seem reasonably stable.

[jacob]

You can consider what you want, but even just being able to read the drives is "better than no support at all"

That said, why not using the FUSE driver. The device (USB drive or card)'s own performance is going to be the bigger bottleneck anyway.

Exactly. The FUSE driver works reliably (at least for me) and on the type of devices exFAT is used for, there is no performance overhead. Not everything needs to or should be in the kernel!

[SystemCrasher]

I don't trust ntfs-3g to write to NTFS either,

I'd say "it works", to extent I used that to write some stuff for windows users and it did what it meant to. However, it is slow. And speaking for myself, once I got idea Linux is my OS of choice, I got rid of NTFS everywhere. Whatever, fuse is slow cpu hog. It brings painful CPU use even on powerful computers, and CPU easily becomes bottleneck on weaker computers. Same stands for exFAT.

and the kernel driver has better read performance AND its less likely to disconnect on i/o errors. That's the main reason I'd even want to mount NTFS on Linux, to retrieve data.

This said, I've read some files from partially damaged NTFS filesystems using fuse and linux. Most ironic part? Windows was not able to mount these, just facing BSOD when trying to do so XD. Seems MS still can't iron out bugs in their drivers, not to mention fuzzing testing, filesystems test suites and somesuch.

No, the kernel driver's write support isn't safe (much less safe than ntfs-3g), that has not changed. The only thing that's safe is writing to a file without changing the length

That sounds a bit too restrictive to me for my use cases. Though I don't really use NTFS on daily basis - that's why I don't care much about its performance . But where I did, I got rid of NTFS, to begin with. NTFS can be slow even in its native implementation. Create just some 50K files in single dir. Now reboot windows (sorry, buffered files access = cheat), try to open that... eh, so much for filesystem performance, eh?

[Grogan]

That sounds a bit too restrictive to me for my use cases.

One valid use case for not changing file length, is blanking a password hash in the Windows SAM registry database. (e.g. chntpw)