Open kapitainsky opened 7 months ago
Ya, happy to merge a PR, if it's a simple change
FUSE-T is a C library implementing the same C API as libfuse
, right? I don't see how that'd work here.
It seems like there was a PR for this -- https://github.com/cberner/fuser/pull/225 -- but it was rejected. I'm not sure whether it ever worked or whether the reason was the closed nature of FUSE-T or whether it was something else.
Oh, I see that fuser has support for the C libfuse library as an optional feature. I didn't realize that before.
(Maintaining that moral-equivalent of ifdef hell can't be fun.)
as kext support on macOS is effectively history would you consider supporting alternatives like FUSE-T? On all new macs (ARM based) running kext requires lowering all system security - and soon will be gone for good given Apple dev announcements (no 3rd party kernel extensions).
Good news is that people are already working on alternatives:
https://www.fuse-t.org/
"It implements its own userspace server that converts between FUSE protocol and NFS calls and let macOS mount NFS volume instead of a kernel filesystem"
and is fuse API compatible so usually is very easy replacement (just linking to fuse-t libs instead of macfuse)
Info for developers - https://github.com/macos-fuse-t/fuse-t/wiki
"In general, the code that worked with osxfuse should work as-is without any changes except linking to a new fuse-t library provided in the installation package."