Open cielavenir opened 3 years ago
I'm personally testing company's system on WSL. Recently it started to use fuse. But I want to keep VirtualBox, which forces WSL1. Then I found this project. I love it 👍 The only thing is it uses bazil/fuse driver (the one zipfs uses).
One important problem is that winfuse uses its own mount protocol that requires a special fusermount
program that replaces the default one from libfuse. A project like bazil/fuse does not use fusermount
and will therefore not currently work with winfuse.
For an explanation of the mount protocol issue see LIMITATIONS / Mount protocol in the release notes.
It does use fusermount program https://github.com/bazil/fuse/blob/master/mount_linux.go#L70
Thanks for clarifying. Have you had success with bazil/fuse on top of winfuse then?
No. That's why I created the issue.
I'm not sure how to take a look. gdb -ex=r --args
could be used (I need to compile winfuse to get debug symbol though)
The main issue seems gone by https://github.com/cielavenir/fuse/commit/abf68fe597b73c545b7465410dbf2a85154113d0 , namely by removing fusermount piping. Not sure if this is because of Golang issue or WSL issue. Without this patch I can see fusermount is launched twice (and one of the two becoming defunct) somehow.
(Well, I'm not sure, but is stdout pipe is inherited to fusermount_helper? If so it should be closed in fork path.)
However the story does not finish. I'm going to use https://github.com/cielavenir/pts-fuse/blob/patch-1/fuse0.py from now on.
During reading bar.txt, I dumped data
content in https://github.com/cielavenir/pts-fuse/blob/patch-1/fuse0.py#L797 .
On Debian 'bar.txt\x00' was shown, but on WSLFuse 'bar.txt\x00\x00\x00\x00\x00' was shown. There are more trailing null bytes. Maybe C does not care about this trailer, but Python and Go need to care it.
Note that patch-1/fuse0.py is my fork but the original https://github.com/pts/pts-fuse/blob/master/fuse0.py could not be used for discussion because lookup fails and this matter is fatal.
Similar stuff in bazil/fuse: https://github.com/bazil/fuse/blob/master/fuse.go#L623
I set the flag value 4 in https://github.com/cielavenir/pts-fuse/blob/patch-1/fuse0.py#L1193 instead of 0. This is FOPEN_NONSEEKABLE according to https://github.com/libfuse/libfuse/blob/master/include/fuse_kernel.h#L244 . Then dumped the reading bar.txt request value in https://github.com/cielavenir/pts-fuse/blob/patch-1/fuse0.py#L1205 .
Debian
0
4096
39
WSLFuse
0
4096
39
0
131072
39
39
131072
0
The WSLFuse's read sequence is not consistent with non-seekable IO. In this way zipfs read fails.
in fuse0.py, hi/hello.txt mode is 0o600. However the file is readable on Debian but not readable on WSLFuse. I can see open->read sequence on Debian but open->getattr->read sequence on WSLFuse. This is minor though.
# For me, http://ptspts.blogspot.com/2009/11/fuse-protocol-tutorial-for-linux-26.html was so helpful to analyze these matters.
Changing https://github.com/cielavenir/pts-fuse/blob/patch-1/fuse0.py#L316 from subprocess.check_call
to subprocess.check_output
breaks the funtionality, which supports my assumption fusermount does not work if stdout is pipe
. I believe fusermount has problems with clients without libfuse. Could you take a look?
@cielavenir sorry for long delay in response. I am still very busy with other work and have not had the time to look into this more closely. I am on vacation soon but hoping to have time after this, in a couple of weeks or so.
@billziss-gh Have you take a look at this?
please... to migrate to WSL2 I'm teased to buy VMWare 17.0 (when it is out)...
after broadcom acquiring vmware, I feared license could change to subscription, so bought VMware anyway.
so I'm not bothered from this matter anymore and not updating this thread anymore.
but please note that not all people can purchase vmware...
https://github.com/bazil/zipfs
Error message:
I don't have the issue on a Debian machine.