Unable to use fuse-t from winfsp/cgo-fuse

[thallgren]

I'm unable to build and run an app that uses winfsp/cgofuse.

The first problem is that the build assumes that the fuse headers on a darwin system resides under /usr/local/include/osxfuse/fuse. Seems the installer for fuse-t puts them under /usr/local/include/fuse.

The second problem is that even if I copy the files into their expected location, and the build succeeds, I will not run. Instead, it fails with:

panic: cgofuse: cannot find FUSE

goroutine 39 [running]:
github.com/winfsp/cgofuse/fuse.(*FileSystemHost).Mount(0x140002481c0, {0x1400022e3c0, 0x59}, {0x14000270000?, 0xa, 0x10})
    /Users/thhal/go/pkg/mod/github.com/winfsp/cgofuse@v1.5.0/fuse/host.go:610 +0x694

Everything works if I instead install macFUSE.

[macos-fuse-t]

You don't need to copy files to a different location. what needs to be done:

1. change include path to /usr/local/include/fuse (-I/usr/local/include/fuse cxx flag)
2. change link library to /usr/local/lib/libfuse-t.dylib (-lfuse-t linkage flag) take a look at https://github.com/macos-fuse-t/cgofuse. I committed the necessary changes

this is an example of how it has to be done https://github.com/macos-fuse-t/cgofuse/commit/3e7192100b68c160a795c2f63059702eb14d46db

[thallgren]

Thanks. That's good info.

And yes, I can start maintaining my own fork of winfsp/cgofuse, or use your fork, but I'd like to stick with the original and enable our users to select their preferred fuse implementation. After all, you claim in your README that fuse-t is a: Drop-in replacement for 'macfuse' (https://osxfuse.github.io/). API headers in libfuse are unchanged so there's no need to change anything in filesystem implementation.

If you want to honor that claim, you'll need to make headers and shared library available using the same paths.

[macos-fuse-t]

I cannot overwrite someone else's libraries in the official distribution, it's not a good practice. But you definitely can if you wish, just overwrite libosxfuse.dylib with libfuse-t.dylib in /usr/local/lib. That way precompiled binaries would work with fuse-t instead of osxfuse. As for drop-in claim, what I mean you don't need to change your code, only the compilation settings. I will add that info to FAQ.

[thallgren]

That's unfortunate. Does that mean that brew doesn't provide a mechanism to use alternative implementations? Couldn't brew link be an option here? IMO, if you do collide with macFUSE, then reporting that as a conflict and refuse to install would be a good thing. It's hard to imagine that a user would want both installed.

[thallgren]

And also, "only the compiler settings" is not a minor thing, considering that you need to create your own fork and change your dependencies. What if I depend on something that in turn depend on winfsp/cgofuse? Or if that dependency is even further down the chain?

[macos-fuse-t]

As I already said, official fuse-t distribution won't overwrite osxfuse libraries, you can do it manually on your system. if your code depends on winfsp/cgofuse it should just work. You can even create your own brew formula for fuse-t that overwrites the libraries, I don't mind that. Even better, create a brew formula for your product that includes the fuse-t runtime.

[thallgren]

It's not me who will install this. It's all users of the thing I create, and I would very much like to avoid giving them advanced instructions on how to manually modify their systems. I would strongly recommend that you declare fuse-t as a conflicts_with macFUSE, and either overwrite or symlink to get things into the correct place.

[macos-fuse-t]

I'll think this over.

[thallgren]

Let me know if there's anything I can do to help out.

[macos-fuse-t]

May I ask you what's the product?

[thallgren]

The product is telepresence. We mount remote filesystems using the now unmaintained sshfs and recently introduced go-fuseftp.

[djdv]

https://github.com/macos-fuse-t/fuse-t/issues/4#issuecomment-1249032175 For what it's worth, I wanted to use fuse-t for my CI tests and that worked for my builds (which depend on cgofuse): https://github.com/djdv/go-filesystem-utils/blob/690ecbcca1fc4c4e01bfe85ab8c81856613435e0/.github/actions/setup/fuse-t/action.yaml

@macos-fuse-t @billziss-gh Would it be possible to conditionally use the changes in that reply above? So that during compile time either macfuse or fuse-t could be used with an ifdef, and during runtime the lib path could be checked? I imagine this would allow cgofuse to work with fuse-t without needing to modify the host system.

[macos-fuse-t]

I suggest that a simple change in cgofuse would be enough since cgofuse loads fuse library in the runtime with dlopen() call. For example, check env variable and load the corresponding library accordingly

[billziss-gh]

It might be as simple as adding an additional dlopen call for the macos-fuse-t dylib here.

Maybe make it read (based on commit 3e71921):

    h = dlopen("/usr/local/lib/libfuse.2.dylib", RTLD_NOW); // MacFUSE/OSXFuse >= v4
    if (0 == h)
        h = dlopen("/usr/local/lib/libosxfuse.2.dylib", RTLD_NOW); // MacFUSE/OSXFuse < v4
    if (0 == h)
        h = dlopen("/usr/local/lib/libfuse-t.dylib", RTLD_NOW); // fuse-t

[billziss-gh]

FYI, my understanding is that @djdv added support for FUSE-T in cgofuse in a couple of recent PR's, so perhaps this can be closed?

[footlooseboss]

FYI, my understanding is that @djdv added support for FUSE-T in cgofuse in a couple of recent PR's

that is also my understanding

so perhaps this can be closed?

if I'm reading correctly, this part of the issue is still open:

@thallgren ... declare fuse-t as a conflicts_with macFUSE, and either overwrite or symlink to get things into the correct place.

@macos-fuse-t I'll think this over.

Perhaps a new issue on this specific topic.