3rd party supporting a file system would be one of the last things on a list of all software I’d ever want a 3rd party writing instead of the OS maker.

Nightmare to evaluate the options, pure stress testing the options, difficult to know if it didn’t mess something up.

>3rd party supporting a file system would be one of the last things on a list of all software I’d ever want a 3rd party writing instead of the OS maker.

Given how many people use FUSE, Paragon NTFS for Mac, and similar tools, you're hardly totally representative.

Third party read-write NTFS drivers took FOREVER to become really robust. I remember hearing horror stories not infrequently up until maybe a decade or less ago.

> Given how many people use FUSE

What percentage of MacOS users even know what that is. I mean I am in the percent but I know it's sub 0.001

MacOS users' awareness of a mostly linux centric piece of tech is pretty damn irrelevant here. The point is that FUSE is a pretty mature piece of technology, and we know that it can be used productively without being that nightmare scenario you described. There is no reason why Apple's FSKit can't be equally successful.

They don’t need to know it to use it. I’ve seen a fair number of commercial cloud drive products use it.

Well there’s at least two of us.

> Given how many people use

How many people use software like this because they have no choice? I used Paragon NTFS, but the entire time, I thought it was ridiculous that MacOS can't read NTFS on its own.

Do many people use macFUSE? I thought ever since the license change it's really dropped off.

There's fuse-t, which uses a local network filesystem in the background, iirc.

Edit: but to be fair, that's mostly only relevant for unsupported network filesystems like sshfs...

They trust kernel extensions apparently, all of them.

Like 99% of the computer using world until less than a decade ago, when almost all drivers were kernel extensions and things like kexts were very much used?

That being said: FSKit is a userspace API. In that respect, it's a lot better than filesystem code running in the kernel - it can't crash your computer or corrupt data on other filesystems, and it's much more tightly sandboxed if it gets exploited.

Exactly! Third party file systems support in user space is exactly what I want to see. It seems to me that third party kernel code has always caused me problems. By moving the FSKit to user-space, I’m quite happy to try something, knowing that it won’t affect the rest of my system.

What would Apple's incentive be to support Btrfs, Ext4, XFS or ZFS ?

Btrfs, Ext4 and XFS are all under GPLv3, which may or may not be a problem for Apple, but "just in case".

They tried with ZFS, but couldn't strike a deal with Sun/Oracle, so instead invented APFS.

Apple already delivers a stable filesystem. It may not be "best of breed", but it works, as billions of devices runs on it every day with zero problems.

Question, who maintains NTFS support for Linux? Microsoft? The kernel? The distros? Genuinely asking.

The current ntfs3 driver is developed by a company called Paragon, and it's been part of the kernel since 5.15 or so.

I was going to add some additional comments about this, but then I found that Paragon's website has an FAQ that covers everything I was going to say (and more): https://www.paragon-software.com/us/home/ntfs3-driver-faq/

The kernel is built with the NTFS3 driver, provided by Paragon.

https://www.paragon-software.com/home/ntfs3-driver-faq/

I'd be happy for VeraCrypt not to have to rely on MacFuse which requires I go turn off some very low-level protection to even use. It sounds like this makes that possible.

I don't really understand your objection to be honest. Drivers for storage are common on other platforms

Is it actually supported and usable now? I seem to recall it spending a lot of time in a "half-documented and not actually available" state.

Thanks for sharing about this! I didn't know, and I like to use (or at least play with) some third-party filesystems on macOS.