-
Notifications
You must be signed in to change notification settings - Fork 21
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
fusermount does not work if stdout is pipe / various other issues #7
Comments
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 👍 |
One important problem is that winfuse uses its own mount protocol that requires a special 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. |
main issueThe main issue seems gone by cielavenir/fuse@abf68fe , 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 issuesHowever 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 longDuring reading bar.txt, I dumped 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 ignoredI set the flag value 4 in https://github.com/cielavenir/pts-fuse/blob/patch-1/fuse0.py#L1193 instead of 0. Debian
WSLFuse
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. |
Changing https://github.com/cielavenir/pts-fuse/blob/patch-1/fuse0.py#L316 from |
@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.
The text was updated successfully, but these errors were encountered: