Comments (47)
OpenBSD apparently supports fuse and libfuse now so maybe cgofuse could too?
Likely, but it would mean setting up and testing against a system that I have never used.
Does rclone currently support OpenBSD (outside the mount command)?
from cgofuse.
Does rclone currently supports OpenBSD (outside the mount command)?
It does yes. However I don't test against OpenBSD, and I think building a native binary will be difficult.
Unfortunately it seems like xgo doesn't support OpenBSD though which would make creating automated builds very difficult.
from cgofuse.
It might be nice to build BSD support, but I agree that without xgo builds would be difficult. We would probably have to also update xgo to support BSD.
I might look into all this in the future, especially if you get more than one person asking for it. I am rather short on time right now though.
from cgofuse.
I'm interested in NetBSD port.
from cgofuse.
@krytarowski does NetBSD support FUSE? Can you point me to good documentation?
Would you have the time to contribute any changes?
A search finds this: https://www.netbsd.org/docs/puffs/
from cgofuse.
NetBSD supports 3 implementations for fuse: fuse
, perfuse
, refuse
.
They vary in the scope of implementation. I recall that one of them is using just high-level interfaces, the other one attempted to support both, and the third one aimed to reuse upstream libfuse library with local patches.
from cgofuse.
I would get one that is completed, fully-featured and fully-compatible with the world. I hope that one of them can work with cgofuse.
from cgofuse.
Reading a bit through the NetBSD docs it seems that librefuse is the way to go. One problem is that it only support the FUSE high-level API and I did have ideas of one day adding FUSE low-level support to cgofuse (once I get it in WinFsp that is).
So we have so far:
Also very importantly we would have to get xgo support for these platforms in order to easily cross-compile and that is a major undertaking. I will shoot a message to the xgo project and see what they are thinking.
from cgofuse.
https://wiki.freebsd.org/WhatsNew/FreeBSD10 notes libfuse work.. but there is an option for wait for requests.
from cgofuse.
FreeBSD information is somewhat contradicting. It does appear that there is good FUSE support in FreeBSD 10 and 11, but good documentation on how to load and use it is lacking. See, for example:
https://forums.freebsd.org/threads/54672/
from cgofuse.
I've never installed FreeBSD, no insight from me.
from cgofuse.
My first attempt at porting cgofuse to FreeBSD is in commit 0acc17d (currently in the freebsd branch).
Most things seem to work:
- General file system use, although no rigorous testing has been done.
- Cleanly unmounting the file system.
A notable exception is that signal handling seems to not be working properly. It is unclear currently why this is the case.
from cgofuse.
Attempting to troubleshoot the signal handling problem in FreeBSD, I am finding that the go runtime does not appear to set signal handlers for SIGINT
, SIGTERM
, etc. under FreeBSD (it does under Darwin).
I added the following code in hostMount
immediately before calling fuse_main_real
:
struct sigaction sa;
memset(&sa, 0, sizeof sa);
sigaction(SIGTERM, 0, &sa);
fprintf(stderr, "sa.handler=%p\n", sa.sa_handler);
This prints on Darwin:
sa.handler=0x403c840
And on FreeBSD we get 0
.
sa.handler=0x0
I believe the FreeBSD response to be incorrect. Shouldn't the Go runtime set its own signal handlers, especially when using os/signal
?
from cgofuse.
Additional information: I traced the system calls during memfs startup using truss
and only kept traces related to sigaction
and SIGTERM
:
sigaction(SIGTERM,0x0,{ SIG_DFL 0x0 ss_t }) = 0 (0x0) <1>
sigaction(SIGTERM,{ 0x4556c0 SA_ONSTACK|SA_RESTART|SA_SIGINFO ss_t },0x0) = 0 (0x0) <1>
sigaction(SIGTERM,0x0,{ 0x4556c0 SA_ONSTACK|SA_RESTART|SA_SIGINFO ss_t }) = 0 (0x0) <2>
sa.handler=0x0 <2>
sigaction(SIGTERM,0x0,{ 0x4556c0 SA_ONSTACK|SA_RESTART|SA_SIGINFO ss_t }) = 0 (0x0) <3>
sigaction(SIGTERM,{ 0x800bc0d90 SA_SIGINFO ss_t },{ 0x4556c0 SA_ONSTACK|SA_RESTART|SA_SIGINFO ss_t }) = 0 (0x0) <3>
My analysis:
<1>: the Go runtime tests and sets a SIGTERM
handler. It uses the SA_ONSTACK|SA_RESTART
flags.
<2>: The modified hostMount
executes sigaction
and fprintf(stderr)
. It finds no SIGTERM
handler.
<3>: Libfuse executes fuse_set_signal_handlers
. It also finds no SIGTERM
handler and for this reason it sets its own.
I cannot explain why after SIGTERM
is set by the Go runtime, FreeBSD then reports that it is not set.
EDIT: for completeness I checked both sa_handler
and sa_sigaction
, although my understanding is that they overlap on FreeBSD. Both fields were 0:
sa.sa_handler=0x0, sa.sa_sigaction=0x0
from cgofuse.
I have merged into master, although I cannot cut a release as signal handling remains broken in FreeBSD.
from cgofuse.
Good progress.. it's worth to discuss it with upstream go developers.
from cgofuse.
I believe I have found the reason for the "mysterious" sigaction
behavior. I also believe that it is a Golang problem and I will report it as such.
The following simple cgo program:
package main
/*
#include <stdio.h>
#include <signal.h>
static void sigprint(int sig) {
struct sigaction sa;
int ret = sigaction(sig, 0, &sa);
fprintf(stderr, "ret=%d handler=%p\n", ret, sa.sa_handler);
}
*/
import "C"
import "syscall"
func main() {
C.sigprint(C.int(syscall.SIGTERM))
}
Succeeds (prints non-0) on Darwin and Linux:
$ go run sigbug.go
ret=0 handler=0x4034150
But fails (prints 0) on FreeBSD:
$ go run sigbug.go
ret=0 handler=0x0
The reason that this happens is that the Go runtime invokes sigaction
using SYSCALL
. However FreeBSD expects that C (and cgo) programs should use the libc sigaction
, which is "interposed" by libthr to __thr_sigaction
. Libthr maintains its own copy of sigaction
's and overrides what the kernel returns.
A likely fix for this is to do what Linux does for sigaction
. Invoke it using SYSCALL
if "!cgo" or use the C library sigaction
if "cgo". See rt_sigaction
.
from cgofuse.
Turns out this is fixed on the current go repo tip. So the FreeBSD port should work without problems once Go 1.11 is out.
from cgofuse.
NetBSD wants to obsolete syscall(2) as this isn't that much portable across CPUs. Ideally we would call C symbols in C.
from cgofuse.
I ended up adding support for OpenBSD in commit c3f5fa1. NetBSD support will have to wait for the next rainy Saturday :)
This support is experimental. It has known issues that stem from the differences in the OpenBSD libfuse implementation from the reference libfuse implementation.
- Signal handling is broken due to a bug in the OpenBSD implementation of fuse_set_signal_handlers
.
- Option parsing may fail because the fuse_opt_parse
function is not fully compatible with the one in libfuse.
An additional caveat is that in OpenBSD only root can mount and unmount FUSE file systems. There used to be a kern.usermount
option, which allowed non-root users to mount file systems, but it was removed in OpenBSD 6 [link].
Finally note that because of the lack of a CI solution for BSD, it will be hard for me to maintain all these ports. I expect that bitrot will eventually set in for the BSD ports.
from cgofuse.
I am on vacation and slightly jetlagged so I am working on NetBSD support. Will see where I get :)
In other news I have created Poor Man's CI for testing the BSD ports. It runs on the Google Cloud and currently supports FreeBSD. Will try to add NetBSD and OpenBSD support for it.
from cgofuse.
good progress!
from cgofuse.
@krytarowski good to hear from you.
BTW, how do I get Go 1.10 for NetBSD? Do I have to build it myself? (Even if that is the case I still need a bootstrap Go for NetBSD from somewhere.)
from cgofuse.
The typical way is to get pkgsrc. lang/go is 1.10.3 http://pkgsrc.se/lang/go
pkgsrc.org has some instructions.
Please note that there might be need to install mozilla-rootcerts for https.
from cgofuse.
Hmmm... I was misled by the list linked below, which does not appear to list a Go(?):
http://ftp.netbsd.org/pub/pkgsrc/current/pkgsrc/devel/README.html
I just tried the following and it worked.
export PKG_PATH="ftp://ftp.NetBSD.org/pub/pkgsrc/packages/NetBSD/x86_64/7.1.2/All"
pkg_add -v go
from cgofuse.
I indeed needed mozilla-rootcerts
to be able to git clone
. Thanks for the pointer.
from cgofuse.
go is in lang, not devel.
from cgofuse.
Makes sense. Just learning my way around NetBSD, hence the n00b mistake.
BTW, I got this to the point of passing most basic smoke tests, but have to troubleshoot a SIGSEGV
, while calling fuse_opt_free_args
. Getting very late now and the jetlag "boost" is gone, I will continue tomorrow.
from cgofuse.
NetBSD support was added in commit 3bc5ead.
from cgofuse.
This looks great! Thank you.
from cgofuse.
@krytarowski I am attempting to add NetBSD support to Poor Man's CI so that I can regularly test the NetBSD port using the Google Compute Engine.
I am currently using NetBSD 8.0_RC2, but I am not clear on how I should setup my PKG_PATH
. I currently have it set as ftp://ftp.netbsd.org/pub/pkgsrc/packages/NetBSD/x86_64/8.0_current/All
, but I get warnings such as:
pkg_add: Warning: package `curl-7.55.1nb1' was built for a platform:
pkg_add: NetBSD/x86_64 8.99.1 (pkg) vs. NetBSD/x86_64 8.0_RC2 (this host)
Any pointers on what PKG_PATH
I should use for 8.0_RC2? I did try replacing 8.0_current
with 8.0_RC2
, but that did not work.
from cgofuse.
Please try: http://ftp.netbsd.org/pub/pkgsrc/packages/NetBSD/x86_64/8.0_2018Q1/All/
8.99.1 is NetBSD-current and 8.0 was branched a year ago.
from cgofuse.
Thank you. This works without warnings.
from cgofuse.
Thank you for the port! I wonder whether perfuse would work better in NetBSD... we tend to have too many features for the same thing. 3 fuse implementations.
from cgofuse.
There are indeed 3 choices in NetBSD.
-
The canonical one is
libpuffs
, which best represents the kernel capabilities. However it does not have a FUSE compatible interface and therefore can not easily be used by cgofuse. -
The
librefuse
implementation is a FUSE compatibility layer on top of PUFFS. It appears to be the natural choice for cgofuse. -
The
perfuse
implementation is an emulation of the/dev/fuse
linux kernel interface using an external daemonperfused
. This is useful to FUSE "low-level" file systems, but introduces an unnecessary extra layer for cgofuse thus adding complexity and inefficiency.
I think that despite some incompatibilities librefuse
is the right choice.
from cgofuse.
I see. Thank you for making it clear.
From a NetBSD developer point of view perhaps it looks like it would be the best to sync the kernel capabilities with Linux and get feature parity in libpuffs.. and keep an option for RUMP/PUFFS users with librefuse and export there low-level parts.
The libperfuse option can be kept around as an intermediate form to get the job done on NetBSD.
Your work is highly appreciated and thank you for the NetBSD port!
from cgofuse.
@krytarowski you are welcome :)
from cgofuse.
@krytarowski sorry to bother you again. I am facing a NetBSD failure while doing Continuous Integration using Poor Man's CI.
I note that cgofuse compiles and runs fine under NetBSD 7.1.2 (on my local VM) but fails when run under NetBSD 8.0_RC2 in the Google Cloud.
Here is the build log:
+ export GOPATH=/tmp/go
+ mkdir -p /tmp/go/src/github.com/billziss-gh
+ cp -R /tmp/repo/cgofuse /tmp/go/src/github.com/billziss-gh
+ cd /tmp/go/src/github.com/billziss-gh/cgofuse
+ go build -v ./...
github.com/billziss-gh/cgofuse/fuse
# github.com/billziss-gh/cgofuse/fuse
In file included from /usr/include/puffs.h:44:0,
from /usr/include/fuse.h:41,
from fuse/host_cgo.go:51:
/usr/include/fs/puffs/puffs_msgif.h:595:2: error: unknown type name 'register_t'
register_t pvnr_retval; /* IN */
^
In file included from /usr/include/fuse.h:41:0,
from fuse/host_cgo.go:51:
/usr/include/puffs.h:225:27: error: unknown type name 'register_t'
puffs_cookie_t, int, register_t *);
^
/usr/include/puffs.h:436:1: error: unknown type name 'register_t'
PUFFSOP_PROTOS(puffs_null) /* XXX */
^
/usr/include/puffs.h:505:20: error: unknown type name 'vsize_t'
enum vtype, vsize_t, dev_t);
^
github.com/billziss-gh/cgofuse/examples/shared
BUILD FAILURE
Do you have any idea what the missing register_t
and vsize_t
C symbols are and why this problem happens on 8.0_RC2 but not 7.1.2?
from cgofuse.
BTW, the PMCI integration is currently in the netbsd branch.
from cgofuse.
If this is a C code, please check -D_KERNTYPES
or some equivalent like #define _KERNTYPES
before including headers.
from cgofuse.
Thanks for the hint. Adding -D _KERNTYPES
does indeed allow cgofuse to be built on NetBSD 8.0_RC2.
(As a user of NetBSD I would argue that this should be considered a problem. The need for _KERNTYPES
is not documented in the refuse(3)
man page. Furthermore users of FUSE on other systems would likely not know about _KERNTYPES
.)
In any case I hit an even more serious problem when trying to run some of the cgofuse smoke tests. It does not look that Go 1.10 is ready for use on NetBSD 8.0_RC2 yet :(
It looks like I will have to shelve doing CI for NetBSD, until 8.0 and its associated tooling has matured a bit more. @krytarowski thank you for your help on this.
+ export GOPATH=/tmp/go
+ mkdir -p /tmp/go/src/github.com/billziss-gh
+ cp -R /tmp/repo/cgofuse /tmp/go/src/github.com/billziss-gh
+ cd /tmp/go/src/github.com/billziss-gh/cgofuse
+ go build -v ./...
github.com/billziss-gh/cgofuse/fuse
github.com/billziss-gh/cgofuse/examples/hellofs
github.com/billziss-gh/cgofuse/examples/shared
github.com/billziss-gh/cgofuse/examples/memfs
github.com/billziss-gh/cgofuse/examples/passthrough
+ go test -v ./fuse -run 'TestUnmount|TestSignal'
=== RUN TestUnmount
reqid: 0, opclass 1, optype: PUFFS_VFS_UNMOUNT, cookie: 0x0,
aux: 0x702e1132c038, auxlen: 64, pid: 730, lwpid: 6
since previous call: 1530360048.176428
fatal: morestack on g0
SIGTRAP: trace trap
PC=0x456282 m=0 sigcode=1
signal arrived during cgo execution
goroutine 8 [running, locked to thread]:
runtime.morestack()
/usr/pkg/go/src/runtime/asm_amd64.s:451 +0x22 fp=0x702e1173fd00 sp=0x702e1173fcf8 pc=0x456282
created by github.com/billziss-gh/cgofuse/fuse.testHost
/tmp/go/src/github.com/billziss-gh/cgofuse/fuse/host_test.go:76 +0x278
goroutine 1 [chan receive]:
testing.(*T).Run(0xc4200a40f0, 0x54d4d0, 0xb, 0x555148, 0x46b1b6)
/usr/pkg/go/src/testing/testing.go:825 +0x301
testing.runTests.func1(0xc4200a4000)
/usr/pkg/go/src/testing/testing.go:1063 +0x64
testing.tRunner(0xc4200a4000, 0xc420051df8)
/usr/pkg/go/src/testing/testing.go:777 +0xd0
testing.runTests(0xc42000c060, 0x7fad20, 0x3, 0x3, 0x411779)
/usr/pkg/go/src/testing/testing.go:1061 +0x2c4
testing.(*M).Run(0xc42008e000, 0x0)
/usr/pkg/go/src/testing/testing.go:978 +0x171
main.main()
_testmain.go:46 +0x151
goroutine 5 [syscall]:
os/signal.signal_recv(0x0)
/usr/pkg/go/src/runtime/sigqueue.go:139 +0xa6
os/signal.loop()
/usr/pkg/go/src/os/signal/signal_unix.go:22 +0x22
created by os/signal.init.0
/usr/pkg/go/src/os/signal/signal_unix.go:28 +0x41
goroutine 6 [syscall]:
github.com/billziss-gh/cgofuse/fuse._Cfunc_hostUnmount(0x702e11310200, 0x702e1130b080, 0x0)
_cgo_gotypes.go:554 +0x4d
github.com/billziss-gh/cgofuse/fuse.c_hostUnmount.func1(0x702e11310200, 0x702e1130b080, 0x702e1130b080)
/tmp/go/src/github.com/billziss-gh/cgofuse/fuse/host_cgo.go:704 +0x60
github.com/billziss-gh/cgofuse/fuse.c_hostUnmount(0x702e11310200, 0x702e1130b080, 0x702e1130b080)
/tmp/go/src/github.com/billziss-gh/cgofuse/fuse/host_cgo.go:704 +0x35
github.com/billziss-gh/cgofuse/fuse.(*FileSystemHost).Unmount(0xc420010840, 0x0)
/tmp/go/src/github.com/billziss-gh/cgofuse/fuse/host.go:686 +0x4c
github.com/billziss-gh/cgofuse/fuse.testHost(0xc4200a40f0, 0x457c01)
/tmp/go/src/github.com/billziss-gh/cgofuse/fuse/host_test.go:82 +0x2ad
github.com/billziss-gh/cgofuse/fuse.TestUnmount(0xc4200a40f0)
/tmp/go/src/github.com/billziss-gh/cgofuse/fuse/host_test.go:102 +0x30
testing.tRunner(0xc4200a40f0, 0x555148)
/usr/pkg/go/src/testing/testing.go:777 +0xd0
created by testing.(*T).Run
/usr/pkg/go/src/testing/testing.go:824 +0x2e0
goroutine 9 [chan receive]:
github.com/billziss-gh/cgofuse/fuse.(*FileSystemHost).Mount.func3(0xc420010840, 0xc420060300)
/tmp/go/src/github.com/billziss-gh/cgofuse/fuse/host.go:659 +0x41
created by github.com/billziss-gh/cgofuse/fuse.(*FileSystemHost).Mount
/tmp/go/src/github.com/billziss-gh/cgofuse/fuse/host.go:658 +0x3eb
goroutine 10 [select, locked to thread]:
runtime.gopark(0x555690, 0x0, 0x54c6f3, 0x6, 0x18, 0x1)
/usr/pkg/go/src/runtime/proc.go:291 +0x11a
runtime.selectgo(0xc42002ef50, 0xc4200603c0)
/usr/pkg/go/src/runtime/select.go:392 +0xe50
runtime.ensureSigM.func1()
/usr/pkg/go/src/runtime/signal_unix.go:549 +0x200
runtime.goexit()
/usr/pkg/go/src/runtime/asm_amd64.s:2361 +0x1
rax 0x17
rbx 0x80ea40
rcx 0x459d95
rdx 0x0
rdi 0x2
rsi 0x54fce6
rbp 0xc420040a28
rsp 0x702e1173fcf8
r8 0xc420001980
r9 0xc420001980
r10 0xc42001a070
r11 0x212
r12 0x0
r13 0x10000000
r14 0x0
r15 0x702e1132c000
rip 0x456282
rflags 0x216
cs 0x47
fs 0x0
gs 0x0
FAIL github.com/billziss-gh/cgofuse/fuse 3.419s
BUILD FAILURE
from cgofuse.
We were fixing Go in their HEAD branch.. is it possible to check Go from the HEAD?
from cgofuse.
I propose to file the _KERNTYPES issue to gnats. netbsd.org -> support -> report a bug
If Go is still broken in their HEAD or 1.11, please file a bug for it too.
from cgofuse.
We were fixing Go in their HEAD branch.. is it possible to check Go from the HEAD?
Yes. I will look into it.
from cgofuse.
Ok. I compiled my own Go from golang/go tip. Unfortunately not all tests passed, but I will try to use it for building cgofuse on NetBSD 8.0_RC2 nevertheless.
from cgofuse.
@krytarowski unfortunately the problem persists with latest go :(
builder0# uname -a
NetBSD builder0.c.poor-mans-ci.internal 8.0_RC2 NetBSD 8.0_RC2 (GENERIC) #0: Mon Jun 25 13:01:26 UTC 2018 [email protected]:/
usr/src/sys/arch/amd64/compile/GENERIC amd64
builder0# go version
go version devel +0dc814cd7f Sat Jun 30 01:04:30 2018 +0000 netbsd/amd64
builder0# git checkout netbsd
Branch 'netbsd' set up to track remote branch 'netbsd' from 'origin'.
Switched to a new branch 'netbsd'
builder0# go build ./...
builder0# go test -v ./fuse
=== RUN TestUnmount
reqid: 0, opclass 1, optype: PUFFS_VFS_UNMOUNT, cookie: 0x0,
aux: 0x700f8132c038, auxlen: 64, pid: 1311, lwpid: 6
since previous call: 1530370183.602584
fatal: morestack on g0
SIGTRAP: trace trap
PC=0x45a182 m=0 sigcode=1
signal arrived during cgo execution
goroutine 8 [running, locked to thread]:
runtime.abort()
/usr/pkg/go-custom/src/runtime/asm_amd64.s:840 +0x2 fp=0x700f812ffcf8 sp=0x700f812ffcf0 pc=0x45a182
runtime.morestack()
/usr/pkg/go-custom/src/runtime/asm_amd64.s:397 +0x25 fp=0x700f812ffd00 sp=0x700f812ffcf8 pc=0x458835
created by github.com/billziss-gh/cgofuse/fuse.testHost
/root/go/src/github.com/billziss-gh/cgofuse/fuse/host_test.go:76 +0x26f
goroutine 1 [chan receive]:
testing.(*T).Run(0xc000092100, 0x5530aa, 0xb, 0x55af40, 0x46d486)
/usr/pkg/go-custom/src/testing/testing.go:879 +0x37a
testing.runTests.func1(0xc000092000)
/usr/pkg/go-custom/src/testing/testing.go:1119 +0x78
testing.tRunner(0xc000092000, 0xc000083e08)
/usr/pkg/go-custom/src/testing/testing.go:827 +0xbf
testing.runTests(0xc00000c060, 0x842b00, 0x3, 0x3, 0x40dc8f)
/usr/pkg/go-custom/src/testing/testing.go:1117 +0x2a2
testing.(*M).Run(0xc00008e000, 0x0)
/usr/pkg/go-custom/src/testing/testing.go:1034 +0x165
main.main()
_testmain.go:46 +0x13d
goroutine 5 [syscall]:
os/signal.signal_recv(0x0)
/usr/pkg/go-custom/src/runtime/sigqueue.go:139 +0x9c
os/signal.loop()
/usr/pkg/go-custom/src/os/signal/signal_unix.go:23 +0x22
created by os/signal.init.0
/usr/pkg/go-custom/src/os/signal/signal_unix.go:29 +0x41
goroutine 6 [syscall]:
github.com/billziss-gh/cgofuse/fuse._Cfunc_hostUnmount(0x700f81310200, 0x700f8130b080, 0x0)
_cgo_gotypes.go:554 +0x4d
github.com/billziss-gh/cgofuse/fuse.c_hostUnmount.func1(0x700f81310200, 0x700f8130b080, 0x700f8130b080)
/root/go/src/github.com/billziss-gh/cgofuse/fuse/host_cgo.go:704 +0x60
github.com/billziss-gh/cgofuse/fuse.c_hostUnmount(0x700f81310200, 0x700f8130b080, 0x700f8130b080)
/root/go/src/github.com/billziss-gh/cgofuse/fuse/host_cgo.go:704 +0x35
github.com/billziss-gh/cgofuse/fuse.(*FileSystemHost).Unmount(0xc0000507c0, 0x0)
/root/go/src/github.com/billziss-gh/cgofuse/fuse/host.go:686 +0x4a
github.com/billziss-gh/cgofuse/fuse.testHost(0xc000092100, 0x344801)
/root/go/src/github.com/billziss-gh/cgofuse/fuse/host_test.go:82 +0x2a4
github.com/billziss-gh/cgofuse/fuse.TestUnmount(0xc000092100)
/root/go/src/github.com/billziss-gh/cgofuse/fuse/host_test.go:102 +0x30
testing.tRunner(0xc000092100, 0x55af40)
/usr/pkg/go-custom/src/testing/testing.go:827 +0xbf
created by testing.(*T).Run
/usr/pkg/go-custom/src/testing/testing.go:878 +0x353
goroutine 9 [chan receive]:
github.com/billziss-gh/cgofuse/fuse.(*FileSystemHost).Mount.func3(0xc0000507c0, 0xc00005e300)
/root/go/src/github.com/billziss-gh/cgofuse/fuse/host.go:659 +0x41
created by github.com/billziss-gh/cgofuse/fuse.(*FileSystemHost).Mount
/root/go/src/github.com/billziss-gh/cgofuse/fuse/host.go:658 +0x3d2
rax 0x17
rbx 0x856a00
rcx 0x45c145
rdx 0x0
rdi 0x2
rsi 0x5558f4
rbp 0xc000044a50
rsp 0x700f812ffcf0
r8 0x32
r9 0x32
r10 0x2
r11 0x212
r12 0x0
r13 0x10000000
r14 0x0
r15 0x700f8132c000
rip 0x45a182
rflags 0x216
cs 0x47
fs 0x0
gs 0x0
FAIL github.com/billziss-gh/cgofuse/fuse 3.389s
from cgofuse.
I see, thank you for the test. Please report it on gnats!
from cgofuse.
Related Issues (20)
- Virtio-FS disk not showing after upgrade to 1.9 from 1.9B2. HOT 1
- On macOS, under load, files appearing twice or disappearing when running `ls`, unless `readdir` is sorted HOT 14
- Occasional crash under Windows - use after free? HOT 9
- . HOT 1
- Write method not called HOT 1
- Enable LOCK feature HOT 2
- How to increase buffer size? (max_pages and libfuse3) HOT 1
- Mount and Unmount Result
- Mixup of O_EXCL and O_TRUNC constant values CGO vs non CGO HOT 13
- warning: "FUSE_USE_VERSION" redefined HOT 1
- possible to call cheat engine with cgofuse HOT 1
- Support ARM architecture on Linux
- Incorrect writes from fuse HOT 12
- Need to know when the fuse service is ready HOT 4
- Please provide a way to retrieve information about the fuse implementation
- memfs example problems
- Golang Windows Passthrough version HOT 1
- command line options for Memfs HOT 8
- How can I not let it download video/image files automatically? HOT 3
- Mirrorfs? HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from cgofuse.