It’s surprising that given Apple’s war on kexts, they still haven’t come out with a proper API for implementing local user-space filesystems. It seems like this exists for remote filesystems (eg: Google Drive, Dropbox), but not for filesystems on local storage devices?
Yes, an Apple-supported API is likely coming. They’ve been gradually providing userspace alternatives for kernel extensions. Their API isn’t likely to be FUSE but hopefully the community will develop a translation layer.
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.
Apple started replacing their own file system (and networking) kexts with user-mode file systems in macOS 13. Right now its locked up behind some private entitlements though. Hopefully they open it up more in the future.
It’s certainly been interesting watching the multi-decade arc play out. With Mach as the origins, everything other than tasks (processes) schedule and virtual mem was out of kernel and done over Mach port comms. Then xnu via next step and later OS X linked much more in kernel and exposed specific data types using com+ in iokit. And now more and more is moving back out of the kernel.
io_urging networking on Linux is another similar move out to use space
The linked msdos source code on GitHub has since been rewritten by Apple /again/ [1], so the article is a bit out of date. This happened 3 months ago, and it now plugs into a private framework named FSKit.
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.
Thanks. I was aware of FAT being the first filesystem in userspace (maybe for iOS devices to mount SD cards?) but did not know it was open source or that FSKit existed. Maybe an enterprising hacker could dump the Obj-C header from that framework and start writing a FUSE translation layer.
That's not an argument here. If starting from scratch, might as well go with the thing that works best. Ssh is not an obscure protocol. If it's faster than 9p, that's what I'll use.
It's a network protocol as far as everything from Plan9 was designed to be able to operate over the network in the late 90s sense of " the network is the computer". The local file system of Plan 9 though is exposed locally through 9p
Yeah, and that's one of the reasons plan9 was dogshit and never amounted to anything. "Everything is a file" is bad enough, "Everything is a file which might be 'transparently' across a network" is insane.
Classic blocking I/O is the problem, not network transparency. If you don't want files to be transparent through latency/throughput boundaries, then you should also disable the VFS cache.
Filesystem cache may make latency unpredictable, but it won't make open() unexpectedly fail with ECONNREFUSED. Most programs barely handle ENOENT, let alone EINTR.
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.
> Also, how do you do async fstat and mkdir in Linux? I don't see it in manpages.
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.
Conceptually it's possible: async fstat sets pending read, then epoll could return read flag when it completes, after that fstat completes without delay.
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.
The have the file provider (https://developer.apple.com/documentation/fileprovider/) API. It works by caching the remote files in a system managed cache in APFS. The idea is sound for for Dropbox, GDrive etc, but not a full replacement for FUSE. The nice thing is that it can keep the files locally pre-cached and replicate local changes asynchronously.
My personal desperate hope/wish is some insurance that iSCSI will continue to work and be somewhat performant, either via an API to deal with the kexts or better yet Apple buying Xtend SAN or developing their own and offering first party support. I'm worried though it's not going to make the cut :(
Isn't it already gone from the most recent macOS releases? Or do you mean Apple providing an API that allows implementing a performant non-kext third party initiator?
> they still haven’t come out with a proper API for implementing local user-space filesystems.
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.
I'm not sure "interfere with their own offerings" is quite the right framing. It's more about "going beyond their imagined use case".
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.
My point is their view of a file provider is as a remote file storage API. This is one of the use cases of a file system in user space, but quite different from them generally. Most of the interesting use cases that FUSE covers are completely unsupported by the File Provider API.
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.
I'm not opposed to pointing fingers at Apple when it's justified, but I believe in this case it's really just a matter of priorities.
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.
File Provider is really an API optimized for "synchronizing file systems" (i.e. network file systems with an explicit local cache, e.g. something like Google Drive or Dropbox).
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.
While using network communications is a great workaround for platforms that don't natively support user-mode filesystems, you end up with a bottleneck of data being copied a bunch of times, plus the latency overhead of waking up a thread to accept a new network connection.
Sadly it is NOT a drop in replacement at all and requires recompilation of every app the uses MacFUSE. Thus, it is useful for precisely 0% of fuse-using macOS apps out there. There is a bug in veracrypt GitHub to make fuse-t an option. It has had no action since April.
I upgraded my MBP after keeping MBP 2013 for 10 years and had to go through the shamanic dance of booting Sonoma into the safe mode, changing preferences and rebooting again to get macfuse working and I would still prefer it to dealing with NFS.
Fuse-T works as a drop-in replacement for the traditional FUSE. And pretty good I must say. You don’t notice the NFS part, it’s all handled by fuse-t itself.
I've been using mksquashfs to make full-system backups lately, but had to resort to using unsquashfs for recovering files. This combined with squashfuse might come in handy.
> With each version of macOS it's getting harder and harder to load kernel extensions. Apple strongly discourages it thus making software distributions that use 'macfuse' difficult to install.
omg that's terrible, Apple is so evil
> Additionally, the 'macfuse' kext is unstable, may cause frequent system crashes and kernel lock-ups.
Isn’t Fuse itself LGPL? Thats perhaps one reason since copyleft licenses aren’t favourable from their view.
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.
Macfuse itself has been closed source for a long time. Whether their EULA is compatible with the LGPL though, I don’t know. (Also, the old question: are APIs copyrightable?)
But do they bundle libfuse as a dylib? If they do, they’re probably in the right.
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.
I'd be shocked if there was any technical reason they couldn't; if they haven't, they either don't care or actively don't want to for some reason. (But yes, I think they could and a lot of people would be very happy if they did)
If they ever do this, it’ll probably take the form of a proprietary userspace FS interface that will only work through Finder and will require the binary to be downloaded from the Mac App Store or otherwise signed by Apple. Every dev that wants to use it will have to pay Apple for the privilege.
> 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 [...]
Weird that early in the issue comments the author claims they're going to release source for fuse-t, but then later in the comments changes course and says it's proprietary. Sounds like they originally wanted to release it as open source, but under a restrictive non-commercial license (which is fine, I guess), but then has gone back on that promise.
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.
Especially something like FUSE where it’s potentially the middle man of personal data.
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)
I respect the author's choice to use a proprietary license, but I wish they'd been honest about it.
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.
There are two FUSE implementations for macOS and neither is open source, unfortunately. One reason: it’s a critical component of several profitable, commercial products, but the authors of then-open source FUSE implementations found that none of those companies were willing to financially support their work.
Those authors also haven’t seemed interested in crowdfunding when it has been proposed.
See https://www.theregister.com/2019/12/16/fuse_macos_closed_sou... for more info. I wonder why a dual-licensing approach was not pursued though, e.g. some viral license (AGPL?) for the open-source part. This could have the same benefit of getting companies to negotiate an explicit (paid) license agreement while still making source available.
From the author: right now fuse-t cannot be made open sourced because it won't play nice with existing contracts. You can try my other project which is open source and can be an alternative to fuse:
https://github.com/macos-fuse-t/go-smb2
After Mac OS X.9 I saw which way the wind was blowing and permanently abandoned Mac OS X (now "macOS"). But I do recognize this kext-less FUSE-T thing here as a neat work of art.
This sounds like a nice workaround, though!