FUSE-T is a kext-less implementation of FUSE for macOS that uses NFSv4
github.com
github.com
This sounds like a nice workaround, though!
I wonder if one of the holdups is that they don’t want a profusion of filesystems and would prefer everyone use ExFAT or APFS. Data loss/corruption ultimately results in more support calls and headaches for them, after all.
For a quick overview check out a blog post on threedots. https://threedots.ovh/blog/2022/06/quick-look-at-user-mode-f...
io_urging networking on Linux is another similar move out to use space
I did not immediately see any private entitlements that restrict access to this API, nor is msdos.fs signed with special entitlements on my machine. Chances are this API works for any filesystem by dropping an appex into /Library/Filesystems. Looking forward to this being documented and made public eventually.
[1] https://github.com/apple-oss-distributions/msdosfs/blob/423d...
They have, it's called a File Provider Extension (0). The major downside is that it's extremely limited in what you can provide and it's an extension of the interface on top of APFS and not a proper file system in user space.
Frankly, I don't think Apple cares about creating features that would interfere with their own offerings. User space file systems (to them) are for remote storage. Users should use iCloud. Apps that can't shim over iCloud should be file provider extensions.
If your app doesn't fit in those boxes then Apple doesn't care about providing the APIs to implement it cleanly on their platform. You can hack it through NFS.
iCloud Drive is a File Provider. Third-party services that want to do the same kind of file syncing as iCloud Drive, and thus compete it with it, can. And there are several highly-popular competitors that have recently moved to File Provider, like Dropbox and Google Drive. But when they did so they had to lose some functionality, like the ability to store data on an external drive [1]. And for the less popular use case of third-party filesystems that aren't just for syncing, File Provider is completely inapplicable.
The box covers most of the use cases that most users are using third-party filesystems for. But it's shrink-wrapped around those use cases – no room to invent new ones.
[1] https://talk.tidbits.com/t/dropbox-drops-support-for-storing...
And I believe this is because they want anything that might be useful but competitive with the features they provide their users to be hamstrung by the same design contraints of iCloud and APFS.
My guess is that the number of users that use remote file storage providers is just much larger than that of users using actual (non-SMB) network or local (non-(ex)FAT) file systems, so they created a kext replacement for that use case first.
If anything, the File Provider API levels the playing field between iCloud and third-party remote storage providers, since the neat APFS tricks they can use to implement it would otherwise be unavailable to third party developers. For example, I find Google Drive to be much more well-behaved on File Provider than it ever was when using FUSE (I blame it for some hangs or kernel panics) or SMB (which was more stable, but did not support Spotlight at all).
For all the other use cases, I'm hopeful that we'll be seeing a real macOS FUSE sooner rather than later.
It doesn't seem like a great fit for either network file systems or local file systems: There's mandatory caching, which means everything remote accessed locally is written to disk at least once (completely useless and actively counterproductive for e.g. a local ext4 driver, which is something I dearly miss for fixing Raspberry PI root volumes), and I'm not sure if there's a way to implement remote file locks either.
Microsoft actually uses it for WSL, but afaik does provide the ability to access other 9p servers.
Also, how do you do async fstat and mkdir in Linux? I don't see it in manpages.
AFAIK Plan9 answers to that was to not implement POSIX interfaces, and instead all I/O looked like RPC calls. This is generally a good design idea, but it's hard to sell an OS where all existing software will have to be rewritten for.
io_uring. and a virtual filesystem may have to serve multiple concurrent requests from several threads. so even if individual IO calls are blocking in the aggregate they still have to be interleaved.
Hardly a war, a rather rational decision it is – they are progressively moving kernel modules, drivers, file systems and network components into the user space.
It is a foundational design principle of GNU Hurd where everything, apart from the microkernel server, runs in the user space. Minix 3 followed the same principle, and many other microkernel designs as well.
It makes sense from the resilience point of view where a defective kernel module / driver can no longer crash the entire system.
It also makes sense from the security perspective on – the kernel itself is cryptographically sealed off and can't be tampered with.
Previously, the overhead of extra context switches was too high on the old CPU's and hardware, but today's computing devices are fast and the hardware is more optimised, so moving stuff into the user space is viable and incurs a much smaller performance penalty.
FUSE_LIBRARY_PATH=/usr/local/lib/libfuse-t.dylib
is sufficient. For other binaries, overwriting the libfuse*.dylib with the libfuse-t.dylib should work in the same way.
omg that's terrible, Apple is so evil
> Additionally, the 'macfuse' kext is unstable, may cause frequent system crashes and kernel lock-ups.
oh
I would really love any equivalent API though as dealing with Perforce is a pain in the butt sometimes, and what Microsoft have done with the Prrforce Virtual File system is amazing.
And API copyright aside, how would one prove it’s only API compatible and not using the implementation as well without also open sourcing their implementation?
It would almost be better to be similar but not the same. Then everyone else can just do subtle ifdef changes to their fuse code.
But maybe I’m just being cynical.
> The project consists of two components: libfuse and fuse-t server. libfuse is LGPL licensed and can be downloaded from here: macos-fuse-t/libfuse [1]. You can modify and build it as you wish, the build instructions are provided in the README file. The fuse-t server on the other hand is a proprietary component, it's written in go and doesn't link to or includes anything GPL related, all respective copyright owners are mentioned in License.txt file [...]
I'm not gonna be one of those "proprietary software is immoral" people, but it just rubs me the wrong way to see someone take a concept/protocol that was originally developed in the open and released as open source (the Linux version of FUSE itself), and then build something proprietary.
If there’s concern about other companies profiteering, release it under a license that prevents such and those companies can pay to license under something else.
This approach could even be useful on Linux where fuse isn’t viable (e.g inside containers)
By viable do you mean secure? You can definitely use FUSE within containers, but you do have to cap-add SYS_ADMIN.
I've been tracking that GitHub issue when FUSE-T came out. Initially, the author promised to open source. But then there was a long silence, after which the issue was closed as "completed" without any explanation.
It's unfortunate because proprietary software requires more trust for users. The lack of communication demonstrated here is concerning.
Those authors also haven’t seemed interested in crowdfunding when it has been proposed.