AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |
Back to Blog
Macfuse remove11/29/2023 (And I'm no fanboy I'm super-pissed that Apple is preventing me from reinstalling macOS 11.2.3 on my M1 Mac see. It is my understanding (and I could be wrong) that allowing regularly updated Non-Apple kernel code supporting add'l filesystems (which can have, for example, chowned executables on them*) would make the non-reduced security mode of macOS significantly less secure, no matter what osxfuse does, short of becoming an internal Apple project. OP 3f6a, and all: It seems farfetched to me that this could ever be "fixed". ) are based on the VFS kernel API and I highly doubt Apple is going to reimplement any of these file systems using a new (most likely slower) user space API that has yet to be announced. All native macOS file systems from Apple (APFS, HFS, NFS. They will probably just prevent third party developers from using this kernel API. Apple will most likely not remove the VFS kernel API. is also going to be removed in future versions of macOS? In my case, osxfuse seems to have been made obsolete along the way and imperfectly removed (probably by brew) with some leftover cask metadata in the Caskroom directory. Remove the cask manually with rm -rf osxfuse. Such a full-featured user space API would be a much better fit than using NFS as a backend for macFUSE.ĭoes that mean that support for NFS, SMB, WebDAV etc. Go to the directory where casks are stored with cd (brew -prefix)/Caskroom. That's why I don't think Apple will disable the VFS kernel API without providing a full-featured user space replacement, but that's just my opinion. There is definitely a need for third party file systems on macOS. After it is done - macfuse port should be removed, fuse.pc added as a link to fuse4x.pc, all. Then one-by-one migration can be started. Not knowing Apple's plans for local file systems makes this a very tough decision. /include/fuse4x/.h It requires patches from macports but in this case there will be no conflicts at all. Reimplementing macFUSE to use NFS instead of the VFS kernel API would come at a high price. macFUSE and other file systems are caught in the middle of this.ĭo you think it'd be technically feasible to re-implement MacFUSE as a local NFS (or possibly WebDAV) server acting as a gateway for FUSE filesystems? It's unclear if and when they will announce a non-kernel API for developing full-featured file systems.Īpple announces that all kernel extensions are "bad" and makes using them very cumbersome, but does not officially deprecate file system kernel extensions, because there is no alternative non-kernel API to use instead. In my opinion, the current workflow for using third party file systems on macOS is very user unfriendly and it certainly does not represent the ease of use most users come to expect from Apple products. It rather looks like lock-in at its finest. Consistently killing off the ability to connect to non-Apple local and remote storage does not look like something for the benefit of users.
0 Comments
Read More
Leave a Reply. |