Fuse4X: add port

[anatol (Anatol Pomozov)]

MacFUSE project is dead. The last release has been made in 2008, not supported on 10.5 and 64 bits kernels. MacPorts has a bunch of workarounds to make it work.

Here is MacFuse successor - Fuse4X ​http://fuse4x.org

Fuse4X has 10.6, 64bits support out of box. It also aims to have much closer compatibility with the upstream Fuse version. Fuse4X is based on up-to-date Fuse version 2.8.5 while MacFUSE is based on horribly outdated 2.7.3.

Fuse4X is alive project, while MacFUSE is dead - the author left the project and does not want to add anyone as a developer there.

MacFUSE and Fuse4X can co-exist on the system so one-by-one migration for applications is possible. And when all applications will be migrated - MacFUSE can be retired.

[anatol (Anatol Pomozov)]

Sorry "has been made in 2008, not supported on 10.5 and 64 bits kernels" -> not supported on 10.6

[ryandesign (Ryan Carsten Schmidt)]

So, for now, this is a request to add a port for fuse4x. Then, much later, we can separately consider removing macfuse.

[anatol (Anatol Pomozov)]

I would like to add a Fuse4X port. The Fuse4X consist of 3 parts: kernel extension (kext), libfuse and ObjC framework. kext and framework require xcode to build, libfuse - autotools. kext and libfuse are required.

What is the best example of a port that requires to download and build 3 source archives? ​https://github.com/fuse4x

[mf2k (Frank Schima)]

Can you just make 3 ports? Otherwise look at the qtiplot Portfile for an example.

[drkp (Dan Ports)]

Glad to see you have a release now! I will take a look putting together a port.

The MacFUSE port used to be split into two ports (fusefs and libfuse) long ago -- I think around release 1.0, certainly before my involvement with it. I'm not sure what prompted the switch; probably was that MacFUSE started coming as an xcode project that included the libfuse build too. Having Fuse4X as separate ports seems reasonable to me.

[anatol (Anatol Pomozov)]

It is possible to split it into 3 ports (fuse4x, fuse4x-kext, fuse4x-objc). But I though that as they do not work one without other (and they need to be installed together) it makes sense to keep them in the same port.

@dports - feel free to contact me over email/IM i'll be glad to help you/review the Portfile. I can add the port by myself but it probably take more time.

[anatol (Anatol Pomozov)]

dports - do you work on these ports? If not - I would like to add them.

[anatol (Anatol Pomozov)]

libfuse

[anatol (Anatol Pomozov)]

fuse4x objc

[anatol (Anatol Pomozov)]

fuse4x kernel extension

[anatol (Anatol Pomozov)]

I just added Portfiles for 3 parts of fuse4x: kext, libfuse and framework.

I just installed them locally - everything seems fine. Please review the Portfiles.

[drkp (Dan Ports)]

Looks good in general. I can see a few minor changes that I will make. A couple notes that are worth mentioning:

It would be better if there was a tarball we could fetch rather than checking out a git tag. That would allow people to install it without having git installed, and allow it to be mirrored.

Does the kext need to be installed into /System/Library/Extensions? I'd rather avoid putting things in /System if we can. It only needs to be there if it must be loaded during boot, and I think that isn't true because libfuse will autoload it when needed, right?

[anatol (Anatol Pomozov)]

It would be better if there was a tarball we could fetch rather than checking out a git tag.

The sources can be download as a file. ​https://github.com/fuse4x/kext/downloads

I was not sure how to do it in the Portfile. It requires 'master site' and I did not find an example with github as a master site.

If you can take care of it would be great.

Does the kext need to be installed into /System/Library/Extensions?

Yes. In case if the kext is located here - kexload tool can load the kext without the root password. Fuse starts this kext only when it mounts any fuse filesystem first time.

Theoretically it is possible to start fuse4x at the boot-time. ​http://guide.macports.org/#development.examples.startupitem It means that libfuse should not even try to load the kext by itself as we assume kext is loaded all the time.

[anatol (Anatol Pomozov)]

As of the first issue - I found an example of using tarball from github. Here it is ​https://trac.macports.org/browser/trunk/dports/devel/lua-wsapi/Portfile

Let me know if you are working on it, otherwise I'll do it.

[drkp (Dan Ports)]

Replying to anatol.pomozov@…:

The sources can be download as a file. ​https://github.com/fuse4x/kext/downloads

Thanks. I looked for that but somehow managed to miss it.

Does the kext need to be installed into /System/Library/Extensions?

Yes. In case if the kext is located here - kexload tool can load the kext without the root password. Fuse starts this kext only when it mounts any fuse filesystem first time.

I see, libfuse is loading the kext directly, so it does need to go into /System. IIRC, MacFUSE invoked a setuid binary to do so, I figured you were doing the same.

Theoretically it is possible to start fuse4x at the boot-time. ​http://guide.macports.org/#development.examples.startupitem It means that libfuse should not even try to load the kext by itself as we assume kext is loaded all the time.

I'm having trouble parsing this. It doesn't seem like there's any really compelling reason to force it to load at boot.

[drkp (Dan Ports)]

Replying to anatol.pomozov@…:

Let me know if you are working on it, otherwise I'll do it.

I'll take care of it; I've got some other changes locally as it is.

[anatol (Anatol Pomozov)]

I'm having trouble parsing this. It doesn't seem like there's any really compelling reason to force it to load at boot.

You asked is there any way to keep kext somewhere in the /opt/local. I said that it is possible to do, but in this case kextload needs to be run as a root. The code that checks permissions is here ​http://www.opensource.apple.com/source/kext_tools/kext_tools-177/kextd_request.c search for "not in system extensions or filesystems folder" text.

As a solution I proposed not to use kextload at all. Just load the kext at boot and remove kextload usage from libfuse.

[anatol (Anatol Pomozov)]

Do you need any help? I would like to add a port for fuse4x and later for sshfs and tup than depend on fuse4x.

[anatol (Anatol Pomozov)]

I would like to add a port for fuse4x

-> I would to see fuse4x port added to macports

[anatol (Anatol Pomozov)]

I think in one of the next versions I'll add load_fuse4x setuid binary back. After that kext can be loaded from any location (not only from /System). And BTW macports can do it the same (put kext to any location).

Are any updates on fuse4x port status. Do you need any help?

[drkp (Dan Ports)]

I am working on it. I have it successfully built with some changes to the portfile, but am not yet able to mount a filesystem. Not sure yet what's going on.

While I'm looking into that, some more questions: does it support Leopard systems? I saw some references to 10.6 in a couple places, but is this just an issue of the build system (and testing), or is there something more fundamental?

I noticed the library installs as libfuse4x.dylib rather than libfuse. There's at least one port that will fail to build because it's looking for libfuse directly rather than asking pkgconfig, but maybe that's a bug in itself.

[anatol (Anatol Pomozov)]

but am not yet able to mount a filesystem

What filesystem you are trying to mount? What error it shows? What "grep fuse4x /var/log/system.log" shows?

does it support Leopard systems?

Currently no - there is an issue related to setuid binaries that does not allow to use fuse4x on 10.5. It has been fixed in repository and the next release should work fine on Leopard. But the main problem is that I do not have 10.5 to test fuse4x changes, if we want to mark fuse4x as "supported on 10.5" there should be people that check fuse4x on this OS.

I noticed the library installs as libfuse4x.dylib rather than libfuse

The idea is to make fuse4x and macfuse coexist together on the same computer.

There's at least one port that will fail to build because it's looking for libfuse directly rather than asking pkgconfig

pkg-config seems much better solution. For example package file also includes compiler flags. In any case that port can be fixed later when its moving to fuse4x.

[drkp (Dan Ports)]

Of the three filesystems I've tried so far:

• encfs fails to link; it wants fuse_unmount_compat22 which appears not to be provided by libfuse4x
• sshfs builds but spends all of its time spinning in sem_wait, presumably because of the issue you found where ​| sem_init is not supported
• bindfs works if run as root. As a normal user, I get a permission error: fuse4x failed to mount /dev/fuse4x1 to /private/tmp/foo : Operation not permitted

[anatol (Anatol Pomozov)]

fuse_unmount_compat22

I am surprised that it this fs requires the old interface. I'll look into this issue and restore the old interface.

sshfs builds but spends all of its time spinning in sem_wait, presumably because of the issue you found where

Fuse4X has its own sshfs port ​https://github.com/fuse4x/sshfs that solves all these problems.

bindfs works if run as root

Make sure that /private/tmp/foo is owned by the user. Also check /var/log/system.log - it should contain more info.

[drkp (Dan Ports)]

Replying to anatol.pomozov@…:

sshfs builds but spends all of its time spinning in sem_wait, presumably because of the issue you found where

Fuse4X has its own sshfs port ​https://github.com/fuse4x/sshfs that solves all these problems.

Yep, I can confirm that works. Is fixing the usage of sysv semaphores the only change in your version of sshfs?

bindfs works if run as root

Make sure that /private/tmp/foo is owned by the user. Also check /var/log/system.log - it should contain more info.

No, that's not it (and dmesg was unhelpful). After much debugging, I realized the problem was that bindfs uses -o allow_user by default, and the kext rejects that with EPERM unless the fuse_allow_other sysctl is set or the user is a member of the fuse admin group. What I'm puzzled by is that this works fine with MacFUSE (I just verified this). I don't understand why; the code appears to be the same and the sysctls have the same defaults.

[anatol (Anatol Pomozov)]

Replying to dports@…:

Replying to anatol.pomozov@…:

sshfs builds but spends all of its time spinning in sem_wait, presumably because of the issue you found where

Fuse4X has its own sshfs port ​https://github.com/fuse4x/sshfs that solves all these problems.

Yep, I can confirm that works. Is fixing the usage of sysv semaphores the only change in your version of sshfs?

Yes, it is the only change to sshfs. I moved libsem (semaphores implementation based on pthreads) from macfuse to sshfs. This is more correct place for it.

bindfs works if run as root

Make sure that /private/tmp/foo is owned by the user. Also check /var/log/system.log - it should contain more info.

No, that's not it (and dmesg was unhelpful). After much debugging, I realized the problem was that bindfs uses -o allow_user by default, and the kext rejects that with EPERM unless the fuse_allow_other sysctl is set or the user is a member of the fuse admin group. What I'm puzzled by is that this works fine with MacFUSE (I just verified this). I don't understand why; the code appears to be the same and the sysctls have the same defaults.

Oops, sorry. It is also due to a bug in 0.8.6. But it also fixed in the HEAD. ​https://github.com/fuse4x/kext/commit/392e48a5ce39d313c157622ec40f53f49872a81b

I also made kext messages more helpful for this error.

[drkp (Dan Ports)]

OK, I've tried it using HEAD and bindfs is working OK. I'm going to keep working with HEAD for now and plan on switching to 0.8.7 or some other future release before committing.

Right now I am testing it on 10.5.

[drkp (Dan Ports)]

It looks like there are the following issues for 10.5 compatibility:

• load_fuse4x uses the C API for loading kexts; that doesn't exist on 10.5. Need to fork and exec a kextload instead
• the kext's Info.plist needs different version numbers for its OSBundleLibraries dependencies
• fuse_params.h has PAGE_SIZE undefined. It's probably defined in some header file, but I'm not sure which one. Not sure how much it matters that it actually corresponds to the page size, anyway.
• fuse_internal.c got a missing symbol on vnode_isrecycled. That may have been introduced in 10.6? Seems like this is the biggest problem.

[skl@…]

Replying to anatol.pomozov@…:

fuse_unmount_compat22

I am surprised that it this fs requires the old interface. I'll look into this issue and restore the old interface.

that's not necessary. You could patch encfs too to use fuse_kern_unmount() directly instead of calling fuse_unmount_compat22(). I've successfully compiled encfs 1.7.4 usinsg fuse4x 0.86 on SL and it works like a charm.

[skl@…]

patch for encfs to link against fuse4x 0.86

[anatol (Anatol Pomozov)]

Replying to skl@…:

Replying to anatol.pomozov@…:

fuse_unmount_compat22

I am surprised that it this fs requires the old interface. I'll look into this issue and restore the old interface.

that's not necessary. You could patch encfs too to use fuse_kern_unmount() directly instead of calling fuse_unmount_compat22(). I've successfully compiled encfs 1.7.4 usinsg fuse4x 0.86 on SL and it works like a charm.

I've already added the function back. You can find it in the "pu" branch of fuse subproject. The change should be merged to master soon. I still think that restoring the compatibility is a good thing as other project might depend on it.

[anatol (Anatol Pomozov)]

Replying to dports@…:

OK, I've tried it using HEAD and bindfs is working OK. I'm going to keep working with HEAD for now and plan on switching to 0.8.7 or some other future release before committing.

As you already use "master" branch - you can try to store kext in the macports folders. With master you don't need to put it to /System anymore.

For that you need set correct path to kext (constant FUSE4X_KEXT_PATH) before compiling the project. ​https://github.com/fuse4x/fuse/blob/master/include/fuse_param.h#L18 ​https://github.com/fuse4x/kext/blob/master/common/fuse_param.h#L18

I'll look into other 10.5 issues next week. I am sure that it'll be easy to fix.

[pixilla (Bradley Giesbrecht)]

Cc Me!

[anatol (Anatol Pomozov)]

The change should be merged to master soon.

The fix for fuse_unmount_compat22() is in master already. Please test it.

load_fuse4x uses the C API for loading kexts; that doesn't exist on 10.5. Need to fork and exec a kextload instead

Should be fixed in master.

the kext's Info.plist needs different version numbers for its OSBundleLibraries dependencies

I set KPI version to 9.0.0 (the one used on 10.5). I uploaded it to 'pu' branch.

fuse_params.h has PAGE_SIZE undefined. It's probably defined in some header file, but I'm not sure which one. Not sure how much it matters that it actually corresponds to the page size, anyway.

Hm.. sounds weird this macros should be defined on 10.5. Probably a header file is missed. Please try possible fix in 'pu' branch.

fuse_internal.c got a missing symbol on vnode_isrecycled. That may have been introduced in 10.6? Seems like this is the biggest problem.

Hmm... It is defined in 10.5. Probably header file issue as well. I do not have a fix for it yet.

Please try 'pu' branch and let me know what issues are left.

[anatol (Anatol Pomozov)]

Hmm... It is defined in 10.5. Probably header file issue as well. I do not have a fix for it yet.

Oops I was wrong. This function indeed is not defined on 10.5. I pushed a possible fix to 'pu'.

[nerdling (Jeremy Lavergne)]

Cc Me!

[anatol (Anatol Pomozov)]

I found a small issue with fuse4x_load program. I fixed it and pushed to git master.

[drkp (Dan Ports)]

Seems to be working on Leopard now. There were a couple minor issues -- I'll try to send you a patch tomorrow. I am a bit worried that we will hit the "vnode reclaim in progress" kernel panic; I didn't test it enough to know whether that'll be an issue.

FYI, one of the problems was that I needed to add the <sys/vmparam.h> include to fuse/include/fuse_param.h as well. Easy enough to fix, but since as a rule the fuse/include directory needs to match the kext/common directory, it would probably be a good idea to have some way to ensure they don't get out of sync in the future. Maybe use a git submodule for that?

[drkp (Dan Ports)]

Replying to anatol.pomozov@…:

I noticed the library installs as libfuse4x.dylib rather than libfuse

The idea is to make fuse4x and macfuse coexist together on the same computer.

I contemplated this one some more today and I'm undecided about whether this is a good idea. For one, the benefit is illusory: macfuse and fuse4x won't actually be able to coexist -- at least not in MacPorts, and probably not with a standalone-installed version either -- because both of them want to install $prefix/include/fuse.h in the same place.

It doesn't bother me so much that ports will need to know to link with -lfuse4x instead of -lfuse, even though there are a couple that will need to be patched. But it occurs to me that that does mean migrating from macfuse to fuse4x would require rebuilding all installed filesystems just to link them against a new library. If installing the library under the same name meant that existing file systems would continue to work, that would certainly be desirable.

Of course, all that is predicated on the library actually being ABI-compatible with MacFUSE's libfuse! I imagine it is, but I haven't actually checked.

[anatol (Anatol Pomozov)]

Seems to be working on Leopard now.

Does it mean that <sys/vmparam.h> helped? Are there any other issues? If not - I'll merge proposed fixes to master and start preparing for 0.8.7 release.

I am a bit worried that we will hit the "vnode reclaim in progress" kernel panic; I didn't test it enough to know whether that'll be an issue.

The change comes from Tuxera repository. Macfuse patched by Tuxera works for many people who uses Leopard. But if you see any issues with it - let me know, we'll try to fix it.

one of the problems was that I needed to add the <sys/vmparam.h> include to fuse/include/fuse_param.h as well.

Sure I'll do this once it is clear that <sys/vmparam.h> is a correct fix. I also have a check in the build script that makes sure "common" files are the same in kext and libfuse ​https://github.com/fuse4x/fuse/blob/master/build.rb#L33 If they are different the final distribution (*.pkg) won't be built.

because both of them want to install $prefix/include/fuse.h in the same place.

I had to be more clear - macports and fuse can exist in the runtime (different device filenames, different dynamic libraries), so *users* can install both these packages. But filesystem developers can install only one of the packages as both of them provide the same header files.

The reason for that is that there are few "unofficial" versions of macports that fix different bugs I would like to avoid problems when installing fuse4x instead of this macfuse breaks some software. Additionally fuse4x removes libsem and some functions implementation from libfuse to make it more clear and compatible with upstream fuse. fuse4x uses 64bits inodes by default, while macfuse uses 32bits inodes - many function signatures has been changed. Of course you can patch libfuse at the build time and make it almost ABI-compatible with macfuse.

I would prefer to migrate the filesystems to fuse4x one by one. Thus we have some time to fix possible bugs in fuse4x.

[anatol (Anatol Pomozov)]

I am a bit worried that we will hit the "vnode reclaim in progress" kernel panic;

It makes more sense to use "#ifdef AVAILABLE_MAC_OS_X_VERSION_10_6_AND_LATER", so vnode_isrecycled() will be used if compiled with "-mmacosx-version-min=10.6" flag (i.e. on macports for 10.6). I pushed the change to "pu" branch.

[anatol (Anatol Pomozov)]

macfuse and fuse4x won't actually be able to coexist -- at least not in MacPorts because both of them want to install $prefix/include/fuse.h in the same place.

I see following solutions in this solution:

1) Add fuse4x port first. It is going to conflict with macfuse (because of headers and fuse.pc file). But it is ok, as nobody should install fuse4x (this is just a library that other programs depend on). Once fuse4x is added - change all other program dependencies to fuse4x as one step. It is needed to avoid conflict when both macfuse and fuse4x installed. Right after that remove macfuse port.

2) Change fuse.pc to fuse4x.pc and ./include/*.h location to ./include/fuse4x/*.h It requires patches from macports but in this case there will be no conflicts at all. Then one-by-one migration can be started. After it is done - macfuse port should be removed, fuse.pc added as a link to fuse4x.pc, all dependent ports should change dependency from fuse4x.pc to fuse.pc. Then fuse4x.pc and ./include/fuse4x/*.h be removed (including patches from macports). This way requires more time and efforts though.

[anatol (Anatol Pomozov)]

FYI: Fuse4X released 0.8.7 version. This release includes changes that make Fuse4X work on 10.5.

[anatol (Anatol Pomozov)]

Looking into ​http://trac.macports.org/browser/users/dports/ports/fuse/fuse4x-kext/Portfile

post-activate logic should be following:

1) (Optional step) Check if kext is running: "kextstat -l -b org.fuse4x.kext.fuse4x". if it is not running - we are done.
2) unload the kext using "sudo kextunload /PATH/TO/fuse4x.kext"
3) check if the kext is running. if it is not running - we are done.
4) if previous step shown that the kext is still running - it means that somebody still uses it. We need to ask user either to stop all filesystems and unload kext manually or restart the computer. The list of mounted fuse4x filesystems can be found via "mount -t fuse4x"

[drkp (Dan Ports)]

Here are my current thoughts:

• we are not going to replace macfuse with fuse4x, at least not right away. Both should be available as options; we might also have a port for OSXFUSE. At some later point, if it doesn't look like there are any problems, we can consider changing the default or marking macfuse as replaced_by.
• we do not need to support having more than one FUSE implementation installed, so it's OK if the ports conflict with each other on fuse.h. In fact, it may be better that way because there won't be any question about which one a given filesystem is using. Renaming the header files sounds like it could cause a significant compatibility issue for filesystems.
• the fuse4x ports shouldn't conflict with an installation of MacFUSE installed outside of MacPorts. It doesn't look like they will, which is great since an improvement over the macfuse port. I don't think they will conflict with a standalone Fuse4X installation either although I imagine they won't actually be usable simultaneously unless they're the same version.
• existing filesystem ports should be able to build against either macfuse or fuse4x. This will take some changes but (I think) not major ones. I've already put together a patch for sshfs.
• I'd wanted upgrading from macfuse to fuse4x to not require rebuilding filesystems, but I think that's unrealistic. There are substantive differences between the two, like the fact that MacFUSE has semaphore emulation and Fuse4X doesn't (FWIW, I agree with you that it shouldn't!). So it's OK if switching requires a rebuild.

All of this argues that we're basically in good shape with the portfiles as they are now. I need to test a couple more filesystems, and it would be good to have a release with the Leopard/Lion compatibility fixes I sent you. I also haven't tested anything that uses the Obj-C framework yet. Other than that, I should be able to commit it soon.

[anatol (Anatol Pomozov)]

Replying to dports@…:

Here are my current thoughts:

• we are not going to replace macfuse with fuse4x, at least not right away. Both should be available as options; we might also have a port for OSXFUSE. At some later point, if it doesn't look like there are any problems, we can consider changing the default or marking macfuse as replaced_by.

OSXFUSE was started by Benjamin after I told him that I work on fuse4x and asked him join the project. He rejected my proposal and started osxfuse. I hate when political reason overweights the technical one.

• we do not need to support having more than one FUSE implementation installed, so it's OK if the ports conflict with each other on fuse.h. In fact, it may be better that way because there won't be any question about which one a given filesystem is using. Renaming the header files sounds like it could cause a significant compatibility issue for filesystems.
• the fuse4x ports shouldn't conflict with an installation of MacFUSE installed outside of MacPorts. It doesn't look like they will, which is great since an improvement over the macfuse port.

It is true

I don't think they will conflict with a standalone Fuse4X installation.

They will conflict - standalone and macport fuse4x will conflict in filesystem type and device files (/dev/fuse4xNN).

• existing filesystem ports should be able to build against either macfuse or fuse4x. This will take some changes but (I think) not major ones. I've already put together a patch for sshfs.

It is better to replace sshfs by this one ​https://github.com/fuse4x/sshfs It is also updated to 2.3.0

• I'd wanted upgrading from macfuse to fuse4x to not require rebuilding filesystems, but I think that's unrealistic. There are substantive differences between the two, like the fact that MacFUSE has semaphore emulation and Fuse4X doesn't (FWIW, I agree with you that it shouldn't!). So it's OK if switching requires a rebuild.

It be better to check filesystems that they do not use semaphores from fuse. It can be done by "nm BINARY_FILE | fuse_sem_". And if one uses it - just add semaphores to the filesystem's compat/ like here ​https://github.com/fuse4x/sshfs/blob/master/compat/darwin_semaphore.c

All of this argues that we're basically in good shape with the portfiles as they are now. I need to test a couple more filesystems, and it would be good to have a release with the Leopard/Lion compatibility fixes I sent you. I also haven't tested anything that uses the Obj-C framework yet. Other than that, I should be able to commit it soon.

I have a computer with Lion and I'll run my test suite early next week.

[nicolas.private@…]

Cc Me!

[anatol (Anatol Pomozov)]

• we are not going to replace macfuse with fuse4x, at least not right away. Both should be available as options; we might also have a port for OSXFUSE.

Fuse4X conflicts with macfuse and OSXFUSE. How it should work? I would imagine something like a "virtual" package. i.e. there is will be a virtual package "fuse" and a few implementations (and only one of them can be installed).

At some later point, if it doesn't look like there are any problems, we can consider changing the default or marking macfuse as replaced_by.

I though about replaced_by and it might work for macfuse. For that following changes have to be done:

• kext - nothing as the only user of it is libfuse itself
• libfuse - libfuse should use the same path and the same compiler flags as macfuse. Some changes to ./configure.am required. There is a question about changed macfuse-specific API. Any filesystem that uses only fuse specific API should be fine. Some other filesystems (e.g. SSHFS from macfuse) have to be patched to change it. After fuse4x is installed I can try to compile/check existing filesystems in the macports to see if it conforms fuse API. If it does not make sense to patch a filesystem - then those functions should be added back to fuse4x enabled with -DMACFUSE_COMPAT_MODE define.
• MacFUSE.framework. It is installed outside of the macfuse tree. Symbolic link should be enough (??)

• we do not need to support having more than one FUSE implementation installed, so it's OK if the ports conflict with each other on fuse.h. In fact, it may be better that way because there won't be any question about which one a given filesystem is using. Renaming the header files sounds like it could cause a significant compatibility issue for filesystems.
• the fuse4x ports shouldn't conflict with an installation of MacFUSE installed outside of MacPorts. It doesn't look like they will, which is great since an improvement over the macfuse port. I don't think they will conflict with a standalone Fuse4X installation either although I imagine they won't actually be usable simultaneously unless they're the same version.

Additional clarification: libfuse should not conflict as the library uses different path. In question are kext and framework.

• kext. The same fuse4x cannot be loaded from several places and used at the same time. Following things will conflict between 2 instances of fuse4x kext: filesystem name, device file name, sysctl namespace.
• framework, both macports and standalone installer uses the same path.

Let me know if you want to make macports kext fully independent from standalone version. I'll give you more info about exact places need to be changed in kext.

• existing filesystem ports should be able to build against either macfuse or fuse4x. This will take some changes but (I think) not major ones. I've already put together a patch for sshfs.
• I'd wanted upgrading from macfuse to fuse4x to not require rebuilding filesystems, but I think that's unrealistic. There are substantive differences between the two, like the fact that MacFUSE has semaphore emulation and Fuse4X doesn't (FWIW, I agree with you that it shouldn't!). So it's OK if switching requires a rebuild.

I think it would be possible - compiler flags and installation paths should be corrected in fuse4x. What about MacFUSE.framework?

All of this argues that we're basically in good shape with the portfiles as they are now. I need to test a couple more filesystems, and it would be good to have a release with the Leopard/Lion compatibility fixes I sent you. I also haven't tested anything that uses the Obj-C framework yet. Other than that, I should be able to commit it soon.

[anatol (Anatol Pomozov)]

Just built fuse4x on Lion - it compiles fine. I tested it with sshfs and with my own stress tests for fuse (~100 mount/unmount cycles and 10K requests to filesystem) - everything looks good. I am going to push your changes to git repo soon.

Let me know when you are ready to submit Portfile - I'll create a 0.8.8 tag for fuse4 that includes Lion support as well.

[drkp (Dan Ports)]

If you can wrap an 0.8.8 release with the Lion support, I'm basically ready to commit the portfile.

[drkp (Dan Ports)]

OK, committed in r81149.

Still need to update the various filesystem portfiles to accept fuse4x as a dependency, but I'll open a separate ticket for that.

[anatol (Anatol Pomozov)]

Thanks you very much. In a day or two I'll start converting ports to use fuse4x..

[jonlederman@…]

Hi,

If anyone can help me I would be greatly appreciative. I installed sshfs via macports several days ago and it was working fine. I was connecting to an ubuntu instance. Today it stopped working. The only thing that changed as far as I know is the ip address of the ubuntu instance I am trying to connect to. Now, I get the following error:

Jons-MacBook-Pro:~ Jon$ sshfs localhost:~/Desktop/ ~/mnt -o idmap=jon fuse4x failed to mount /dev/fuse4x0 to /Users/Jon/mnt : Operation not permitted

I also get a dialog box message that says: "The fuse4x failed to mount path". I have no idea what has changed. It sounds like some kind of permissions issue or something with ssh keys. I tried removing ~/.ssh/known_hosts. Is there a way to completely reset sshfs and the configuration and data it may be looking at? But maybe something else is amiss. Any help would be greatly appreciated.

Thanks.

-Jon

[mf2k (Frank Schima)]

@Jon: Use the ​Macports-Users Mailing List for tech support.