Add support for FUSE3 on Linux

[jfantinhardesty]

This pr adds support for FUSE3 on Linux and and makes a slight modification to the FileSystemBase interface to allow building for both FUSE2 and FUSE3. FUSE2 support is maintained and the default build option. To build with FUSE3 support you must use the fuse3 build tag which will then link to fuse3.

Additionally, some of the command line options changed in FUSE3 so direct_io and use_ino can no longer be set as command line options when starting a mount. These must be set in fuse_config so there are some additional functions introduced to set these options.

This also updates the CI/CD to test for FUSE2 and FUSE3 on Linux. It also only checsk the ability to build on MacOS since the old image is no longer available as a GitHub action and requires a restart to test the filesystem in GitHub actions.

This resolves #50.

[billziss-gh]

Great work with this PR. I would love to see a version of this PR incorporated into cgofuse.

Unfortunately the PR as it currently stands makes cgofuse backwards incompatible with existing file systems. It is a goal of this project to maintain backwards compatibility. There are far too many file systems using cgofuse, both open source and closed source to do otherwise.

The main reason for the incompatibility is the change in the Rename, Chmod, Chown, Utimens methods of FileSystemInterface. I would like the FileSystemInterface to remain as is and we could introduce the new method signatures as:

• Either individual small interfaces as it is currently done for (e.g.) FileSystemOpenEx. For example, FileSystemRename3 for the FUSE3 version of Rename.

• Or a whole new FileSystemInterface3 with the new methods.

There may be other options to consider and I am happy to discuss them as long as we maintain backwards incompatibility.

CC'ing @ncw who is (via rclone) one of the biggest open source cgofuse clients.

[ncw]

Very nice. Rclone users have been requesting this 😄

I agree with Bill this shouldn't change the interfaces and break backwards compatibility though.

Can we make the old interfaces work and do something sensible with fuse3. I guess it might require multiple calls to emulate something where a fh is passed in.

Another alternative would be to only provide the new interface when the fuse3 tag is supplied. This would complicate the implementation though.

Another alternative would be to declare a v2 for cgofuse. That would be the least extra code and would give a chance to clean up the Ex interfaces if we wanted.

I thought the whole v2 thing was poorly thought through when I first read about it, but having been through it with some popular packages (eg ncw/swift ) it isn't too scary and works well. We would make a v1 branch which could receive minimal or no support (no support was what I chose) and then master becomes v2.

[jfantinhardesty]

I agree that that it would be better to not change the interface. Based on that feedback, I have added Fuse3 equivalent calls for Chmod, Chown, Utimens, Rename, and Readdir as this seemed to be the easiest to implement. Most filesystems on Fuse3 will not need to implement these methods as I doubt many will use the additional arguments so this means that we can still support Fuse2 and Fuse3 on the original interface by not passing the additional arguments from Fuse3.

[jfantinhardesty]

@billziss-gh Just a gentle ping on if the changes I to keep FileSystemInterface backwards compatible are a good solution.

[billziss-gh]

@jfantinhardesty sorry for that. I have been very busy with real-life events this last couple of weeks. I may be able to find some time to review over the next few days during the holidays.

[billziss-gh]

@jfantinhardesty I am currently working on this. I am using your PR as basis, so your commits will appear in the project's history. As discussed before the goal is to keep backwards compatibility and minimize the changes necessary to support FUSE3 on Linux/FreeBSD.

I have split the FileSystemFuse3 interface to FileSystemChmod3, FileSystemChown3, FileSystemUtimens3, and FileSystemRename3 interfaces. This would allow a file system to support the additional FUSE3 capabilities on a method by method basis. The FUSE3 Readdir interface is not really needed as I think it can be cleanly supported without adding a new Readdir3 method (this is because Readdir already supports a "readdir-plus" kind of capability for Windows which can be adapted for FUSE3 on Linux).

I am basically done with this work and I am now contemplating with how to test the FUSE3 interface/implementation. At the very minimum I will test memfs built with -tags=fuse3, but will likely also look how to test the new FUSE3 methods mentioned above.

[billziss-gh]

FYI this work is currently in the fuse3 branch. There are still some failing tests, which is why I have not fully merged it in yet.

[billziss-gh]

Please have a look at the changes at master...fuse3. With these changes all tests pass on Windows and Linux (both on FUSE2 and FUSE3). It is no longer possible to test on macOS as the GitHub macOS runners cannot load the macFUSE kext.

A couple of TODO's:

• One thing that I have not double checked is that the readdir plus functionality is active under Linux/FUSE3. I think the FUSE3 libfuse enables FUSE_CAP_READDIRPLUS by default, but we should anyway make it controllable by SetCapReaddirPlus.

• Currently cgofuse uses dlsym to retrieve symbols from libfuse. It would be safer to use dlvsym as in: dlvsym(handle, symbol, "FUSE_3.0"). See Changing signatures of exported symbols libfuse/libfuse#1092.

[billziss-gh]

@jfantinhardesty it would be helpful if you had a quick look to verify that these changes will work for you.

[jfantinhardesty]

@jfantinhardesty it would be helpful if you had a quick look to verify that these changes will work for you.

Sorry, currently on vacation. I will have a chance to look at it in a day or two.

[billziss-gh]

No problem. I will wait to merge in, until you have confirmed that the changes work for you.

In particular I am interested in any feedback you may have regarding ReaddirPlus under FUSE3, as we currently have no tests that check for this functionality.