billziss-gh / winfuse

FUSE for the Windows kernel
Other
182 stars 21 forks source link

fusermount does not work if stdout is pipe / various other issues #7

Open cielavenir opened 3 years ago

cielavenir commented 3 years ago

https://github.com/bazil/zipfs

Error message:

USER@DESKTOP:~/zipfs$ ./zipfs hello.zip tmp
(main.go `fuse.Mount()` does not return)

USER@DESKTOP:~/zipfs$ sudo ./zipfs hello.zip tmp
zipfs: mount helper error: fusermount: winmount: no output
zipfs: fusermount: exit status 1
USER@DESKTOP:~$ ls -l /usr/bin/fuser*
-rwsr-xr-x 1 root root 34040 Apr  2 16:33 /usr/bin/fusermount
-rwxr-xr-x 1 root root 30800 Jan 11  2017 /usr/bin/fusermount-glusterfs
-rwxr-xr-x 1 root root  5632 Apr  2 17:02 /usr/bin/fusermount-helper.exe

I don't have the issue on a Debian machine.

cielavenir commented 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).

billziss-gh commented 3 years ago

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.

cielavenir commented 3 years ago

It does use fusermount program https://github.com/bazil/fuse/blob/master/mount_linux.go#L70

billziss-gh commented 3 years ago

Thanks for clarifying. Have you had success with bazil/fuse on top of winfuse then?

cielavenir commented 3 years ago

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)

cielavenir commented 3 years ago

main issue

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.)

other issues

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.

the number of trailing null bytes is too long

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

FOPEN_NONSEEKABLE is ignored

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.

permission should be checked by readability?

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.

cielavenir commented 3 years ago

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?

billziss-gh commented 3 years ago

@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.

cielavenir commented 3 years ago

@billziss-gh Have you take a look at this?

cielavenir commented 2 years ago

please... to migrate to WSL2 I'm teased to buy VMWare 17.0 (when it is out)...

cielavenir commented 2 years ago

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...