fuse-t

> fuse-t uses NFS which is extremely janky and unreliable on MacOS I was wondering what issues you were talking about, and then I found this - https://github.com/macos-fuse-t/fuse-t/issues/45 - data corruption > The fundamental issue is that macOS doesn't provide an API for this natively. The API is there, Apple just doesn’t want to give anyone outside of Apple the entitlement that lets them use it. I don’t understand why Apple won’t. Well, I understand that would require them to document it, ship public headers, and support it for external developers - but why not?

> would rather not install custom ktexts Have you checked out FUSE-T? It's made for that. https://github.com/macos-fuse-t/fuse-t

Does not answer your question directly, but related: https://github.com/macos-fuse-t/fuse-t/issues/1#issuecomment... > 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 [...] [1] https://github.com/macos-fuse-t/libfuse

File Providers are useful in some scenarios, but they are also not really a FUSE equivalent. They're more geared towards Dropbox-like synchronizing use cases. Some developers have made it work for SSHFS too, but even that's already a bit of a stretch; for more custom solutions it definitely falls short: https://developer.apple.com/forums/thread/681325 The only option currently seems to be to implement a network file server such as SMB (which is what Google Drive used to do before File Providers existed!) or NFS, for which there even is a FUSE bridge available: https://github.com/macos-fuse-t/fuse-t

Nice. A similar project, but more license-constrained, is fuse-t for macos: https://github.com/macos-fuse-t/fuse-t

Just for the record: for macOS there’s now https://www.fuse-t.org/ which works without a kext (by spawning a local NFS server in the background and having macOS connect to it) and also has a sshfs implementation listed on https://github.com/macos-fuse-t/fuse-t/wiki#sample-filesyste... .

There’s a new FUSE implementation that uses this technique: https://github.com/macos-fuse-t/fuse-t Worked without problems for sshfs when I tested it briefly.

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 Apple is keeping the API Apple-internal only (although I haven't looked at the Ventura SDK, so I could be wrong about that). But if Apple made the API public, it could be the death-knell of all these commercial FUSE-alternatives for macOS offerings. (Even if Apple's API isn't FUSE-compatible, if it is close enough, someone could easily open-source a translation layer – likely to be a lot simpler than bridging FUSE to an NFS serv

> Also, https://github.com/macos-fuse-t/fuse-t/blob/main/License.txt appears to be "playing lawyer" Do you have any specific concerns with the text of the license? The text seems clear enough that there don't appear to be any potential liabilities from using the software in a personal capacity. As I understand it, the worst that could happen is that the license/software author could unknowingly incur liabilities from statutory or implied warranties - i.e. they left out some important exclusions that could be brought to bear if a plaintiff successfully construed the license as a contract. (IANAL, but I've read a lot about software licenses over the years and have dealt with a legal challenge related to dual commercial/OSS licensing)

I don't know what's going on with the google.com/url encoding of the links on the submitted article Also, one will want to be aware of the currently unsupported features <https://github.com/macos-fuse-t/fuse-t/wiki#unsupported-feat...> since the submitted article appears to be aspirational

That "repo" appears to exist solely for housing the release artifacts, for those who came to the comments looking for "the goods" Also, https://github.com/macos-fuse-t/fuse-t/blob/main/License.txt appears to be "playing lawyer"

Unfortunately, like macFUSE, this is not really open source. The license appears to be BSD-like for non-commercial use only. Also like macFUSE, the project uses GitHub but the source code is not available. https://github.com/macos-fuse-t/fuse-t/blob/main/License.txt