Userspace FUSE for macOS

Post by pjmlp » Tue, Sep 06, 2022, 5:49 AM UTC

ianlevesque wrote: post #107

skissane wrote: post #77

Earlier quoted context omitted.

The developer says they will release source code soon – https://github.com/macos-fuse-t/fuse-t/issues/1#issuecomment... – although keeping the restrictive license. Apple is introducing user-space file system technology in macOS – LiveFS/UserFS/com.apple.filesystems.lifs – some of the infrastructure turned up in Monterey, in Ventura it is actually being used for mounting FAT/exFAT filesystems. It looks like for now Ap…

They have the right to use whatever licensing they want, but it is strange that this one area - FUSE on Mac - consistently attracts developers using weird license restrictions.

Post by fulafel » Tue, Sep 06, 2022, 6:14 AM UTC

EdSchouten wrote: post #11

EdSchouten wrote: post #5

What a coincidence! For a project that I maintain (Buildbarn, a distributed build cluster for Bazel) I recently generalized all of the FUSE code I had into a generic VFS that can both be exposed over FUSE and NFSv4. The intent was the same: to provide a better out of the box experience on macOS. Here's a design doc I wrote on that change. Slight warning that it's written with some Buildbarn knowledge in mind. https:/…

Replying to my own comment: I do wonder how this library deals with some of the fundamental differences beween FUSE and NFSv4. For example, with FUSE the kernel and server share intimate knowledge on which part of the file system lives in the kernel's inode cache. Only when the kernel issues a FORGET call, may the server drop information corresponding to a given nodeid. As NFSv4 is designed to be stateless, servers m…

Post by searealist » Tue, Sep 06, 2022, 6:16 AM UTC

cpuguy83 wrote: post #110

searealist wrote: post #99

Earlier quoted context omitted.

Linux has an extension that allows an arbitrary string that is not tied to the filesystem. This makes it easier to stay within the limit or you can crypto hash an arbitrarily long string down to 108 chars.

This can be pretty dangerous because it is basically the same as using a TCP socket on localhost (assuming you are speaking of abstract sockets).

Post by skissane » Tue, Sep 06, 2022, 7:29 AM UTC

jstarks wrote: post #97

skissane wrote: post #93

Earlier quoted context omitted.

I think the answer on Windows is "No". One could fork a subprocess, chdir()+socket() there, then pass the socket back to parent over another socket (opened maybe with socketpair().) Should work on any Unix-like which supports SCM_RIGHTS (which is almost everybody, apparently even obscure platforms like AIX, IBM i, z/OS). But not Windows, which doesn't (at least not yet, they may add it at some point.) Makes one reall…

In Windows we actually have a way to set the parent directory for a UDS bind or connect, via a socket ioctl. It’s not documented yet, but it’s in the header.

    #define SIO_AF_UNIX_GETPEERPID _WSAIOR(IOC_VENDOR, 256) // Returns ULONG PID of the connected peer process
    #define SIO_AF_UNIX_SETBINDPARENTPATH _WSAIOW(IOC_VENDOR, 257) // Set the parent path for bind calls
    #define SIO_AF_UNIX_SETCONNPARENTPATH _WSAIOW(IOC_VENDOR, 258) // Set the parent path for connect calls
    // NOTE: setting the parent path is not thread safe.

Post by saagarjha » Tue, Sep 06, 2022, 8:01 AM UTC

mrpippy wrote: post #34

macOS Ventura has moved some lesser-used file systems (FAT, exFAT) out of the kernel to user-space, I believe using a private framework developed for iOS (when that added USB mass-storage support). Hopefully they’ll open those APIs up for 3rd party usage on the Mac next year.