Feature Request: libfuse3 support on macOS for FSKit backend

[lvh]

Summary

The jfuse-mac module uses libfuse2, while jfuse-linux and jfuse-win use libfuse3. This creates a functionality gap on macOS where FSKit-based mounting is not available.

Background

macFUSE 5.1.0+ has been adding support for an FSKit backend that allows FUSE filesystems to work without kernel extensions. This matters because Apple has made loading kexts increasingly restrictive - users must boot into Recovery Mode to enable third-party kexts.

The FSKit backend is enabled via -o backend=fskit. Per the macFUSE 5.1.0 release notes, this option is only supported with libfuse3:

"When specifying the mount option -o backend=fskit, libfuse3 will use the FSKit backend to mount the file system."

Since jfuse-mac uses libfuse2, the FSKit option is not available.

Note: FSKit support in macFUSE may still be maturing (see macfuse/macfuse#1070), and FSKit is not a free lunch - it has significant limitations regarding what information is available to the filesystem compared to the kext backend, so compatibility will be limited. Due to these limitations, it may be valuable to ensure failures happen early and clearly so users aren't surprised when filesystems don't work properly with FSKit. However, having libfuse3 support would at least allow users to try it when it's ready.

Current Behavior

$ # Using jfuse on macOS with libfuse2
mount_macfuse: the file system is not available (1)

$ # Attempting FSKit option
fuse: invalid argument 'backend=fskit'  # libfuse2 doesn't recognize this option

Requested Behavior

Update jfuse-mac to use libfuse3 instead of libfuse2, matching the approach used on Linux and Windows. macFUSE ships libfuse3 at /usr/local/lib/libfuse3.4.dylib.

Technical Details

The jfuse-mac pom.xml currently references:

<headerFile>${project.parent.basedir}/libfuse2/include/fuse.h</headerFile>
<cPreprocessorMacro>FUSE_USE_VERSION=29</cPreprocessorMacro>

For libfuse3 support, this would need to change to the fuse3 headers and appropriate version macros.

Questions

1. Is there a technical reason jfuse-mac uses libfuse2 instead of libfuse3?
2. Are there any known compatibility concerns with macFUSE's libfuse3 implementation?
3. Given FSKit's limitations, should jfuse provide a way to detect when FSKit is being used and warn/fail early if the filesystem uses unsupported features?

[overheadhunter]

we are interested in fuse3 on macOS, in particular because of readdirplus performance improvements, however we need to verify it would still work with fuse-t (I believe it only supports libfuse2)

[lvh]

I have no particular feelings about fuse-t but out of curiosity: why is it important to support it? FSKit seems like a generally better method (much more likely to support more features in future versions of macOS), so now macfuse supports it it's not obvious why an end user would prefer fuse-t. If it's just a default "we don't want to break backwards compatibility" that sounds good to me :)

somewhat related: fuse-t makes claims about performance and features:

NFSv4 protocol to better support macOS features such as extended attributes, file locks and others
Performance, FUSE-T offers much better performance and this is due to excellent macOS client side NFSv4 implementation

I don't know what this is in comparison to because I think that language predates macfuse fskit support, and presumably fuse-t isn't really faster than kext macfuse?