-
Notifications
You must be signed in to change notification settings - Fork 274
fuse lib is broken on recent FreeBSD #280
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Ref: restic/restic#3550. |
I don't really use any of the BSDs, it would really be nice to have someone who cares about them work on them. The extra pain of having to find/upgrade/etc a virtual machine to run tests in is enough that I rarely get around to trying FreeBSD. For example, is that error from reading, writing, or Go trying to set up its event polling logic? I don't immediately see why a commit that claims to go from EINVAL to reporting ready for writes would make our syscall say not ready for for writes, so it sounds like it has to be on the read side. We just do a read syscall, Go is probably making the fd nonblocking behind our back -- but we can't just busyloop on a read, it needs to integrate with the poller, and why is that not already working? |
FreeBSD bug report that has some background info: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=258056 |
FWIW This is reasonably easy to add code for, but I just tested FreeBSD 13.1 and am seeing other weird behavior, such as the /dev/fuse FD just hanging after an unmount, instead of the ENODEV it's supposed to give to shut down neatly. And that behavior changes under truss, sometimes working right, sometimes not. Which means I hesitate the complicate the code base, when the end result is still misbehaving -- I don't think I want to add new code just to satisfy FreeBSD until all the tests pass even when run in a loop. I'm not sure I can continue supporting FreeBSD/OpenBSD without engagement with the FreeBSD/OpenBSD kernel development side, and I frankly don't have time or motivation for that personally. Myself, I will prioritize new Linux features over accommodating the BSDs. Ways out of this conundrum: a corporate sponsor telling me FreeBSD FUSE is important to them, or someone stepping up to maintain the FreeBSD side and debugging all the weird hangs I can trigger. |
@tv42 I'm a FreeBSD kernel developer, and the FUSE maintainer. However, I'm not a Go programmer. If you think you've found other bugs in FreeBSD's FUSE driver, I'll fix them. But could you please try to reproduce them in C first? |
Seems that a related problem is at golang: Does it helps? |
That FreeBSD bug, which actually turned out not to be in fusefs, is now fixed. The fix will be included in the next builds of 14.0-CURRENT. |
The upstream library rclone uses for rclone mount no longer supports freebsd. Not only is it broken, but it no longer compiles. This patch disables rclone mount for freebsd. However all is not lost for freebsd users - compiling rclone with the `cmount` tag, so `go install -tags cmount` will install a working `rclone mount` command which uses cgofuse and the libfuse C library directly. Note that the binaries from rclone.org will not have mount support as we don't have a freebsd build machine in CI and it is very hard to cross compile cmount. See: bazil/fuse#280 Fixes #5843
I note that this library no longer compiles with
|
The upstream library rclone uses for rclone mount no longer supports freebsd. Not only is it broken, but it no longer compiles. This patch disables rclone mount for freebsd. However all is not lost for freebsd users - compiling rclone with the `cmount` tag, so `go install -tags cmount` will install a working `rclone mount` command which uses cgofuse and the libfuse C library directly. Note that the binaries from rclone.org will not have mount support as we don't have a freebsd build machine in CI and it is very hard to cross compile cmount. See: bazil/fuse#280 Fixes #5843
@asomers Do you have a pointer to the actual bug / fix in 14.0-CURRENT? |
I think you're talking about this: However, that's not the cause of the build failure described by @ncw. That must be something completely different. |
The non compiling is a Go problem.
Its caused by the package |
A recent change to FreeBSD has broken apps using the bazil.org/fuse lib.
As of the following commit to the FreeBSD FUSE driver:
CURRENT: https://cgit.freebsd.org/src/commit/?id=7b8622fa220b9c08041102f638f848c48e022644
STABLE: https://cgit.freebsd.org/src/commit/?id=7b096a997fad199eddccfb6784e4b85184d9af17
all apps using this lib fail to mount and print a
resource temporarily unavailable
error:All other FUSE-based filesystems that I tested (exfat, (j)mtpfs, sshfs, etc) work just fine after that commit.
The text was updated successfully, but these errors were encountered: