-
Notifications
You must be signed in to change notification settings - Fork 483
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
Use of the libfuse compatibility layer (from fusepy) without cygwin #22
Comments
It is actually possible to use the WinFsp FUSE API without Cygwin. WinFsp provides two different API's:
So the WinFsp FUSE API can be readily used by MSVC Windows apps written in C/C++ (that can include C header files). Regarding FUSEPY: it works on Cygwin (see this PR: terencehonles/fusepy#54), but unfortunately I expect that it cannot currently be used directly by FUSEPY on Windows, because FUSEPY expects to find On Cygwin this gap is bridged by using the cygfuse package, which translates calls to |
Thanks - that would be great. I had already found your branch and given it go :) If I have time, I'll probably have a go at putting together some ctypes bindings for the WinFsp native API. |
That would be great. Keep me posted if you do so. |
Still rather interested in this one if you have some spare time to rejig the exports :) We have our filesystem working now on fuse on Linux, so rather inclined to use that if at all possible via fusepy... |
If it is a Linux fusepy file system, how do you intend to run it on Windows? Via Cygwin or Windows Python? If you are planning to use Cygwin there is now a separate Cygfuse project. This can be readily used by fusepy, because it exports the right symbols ( If you do not want to go through Cygwin, the problem of |
There's nothing very Linux specific about it - the fusepy implementation communicates with a remote system where the data resides. Being able to use winfsp (from a Windows Python runtime) with fusepy would be great. |
Took a quick look at this - exporting the fuse.h functions (just adding the __dllspec(dllexport) instead of static) seems to do the trick for me for the basics. I'll try to get around to running something more complete and let you know. |
@tstordyallison you are correct. This is pretty much how the original version of Cygfuse was implemented: https://github.com/billziss-gh/winfsp/blob/master/opt/cygfuse/cygfuse.c#L62 It may be worth following a similar approach and creating a "Winfuse" DLL that it is just a thin layer over WinFsp.
Fantastic! |
Commit db05667 should fix this issue. See issue #60. I include some of the more relevant comments here:
|
BTW, the fix above makes fusepy usable from native Windows. My fusepy fork already works for Cygwin, and with a couple of minimal changes it also works for Windows. |
Brill. Are you planning on submitting a PR to the fusepy project? Also, what are your thoughts on supporting #44 in fusepy? I found my FS was struggling with thousands of getattr calls... was hoping it would help (especially given the GIL). |
I have already submitted PR terencehonles/fusepy#54 for Cygwin, but it is still lingering. I will update it to include native Windows. We might have to make some noise so that the fusepy maintainer notices :) Hello, @terencehonles!
Issue #44 is already resolved for WinFsp (I think it is included in RC3). We might have to do some extra work on the fusepy side to get it to work, but I think it is a good idea. |
I added billziss-gh/fusepy#1 to track this. |
You may have seen this already from #60, but just in case: WinFsp 2017 is out 🎉 Get it here: https://github.com/billziss-gh/winfsp/releases/tag/v1.0 If this works for you, we can probably (finally) close this issue. |
My fusepy fork now runs on Windows (and Cygwin) without any issues. The changes are in the windows branch. |
Great - I had more or less made the same change locally. The 1.0 is working nicely for me now too, thanks! |
(with the exception that you do a much more proper job of it and look it up in the registry etc!) |
@tstordyallison I am glad 1.0 works for you. Consider adding your voice to the terencehonles/fusepy#54 PR, so that it may be looked at and possibly accepted. I will close this, but will ping you directly if I make additional changes to my fusepy fork (esp. regarding the |
Would it be possible to build the fuse compatibility API to be loadable without cygwin?
If I've understood what is going on properly between fusepy (via ctypes) <-> 'win fsp fuse compat' <-> winfsp then I think it should be.
Would be great for using fusepy directly (and then being able to use the same code, or something close on *nix).
The text was updated successfully, but these errors were encountered: