Re: FUSE for Cygwin

[Bill Zissimopoulos <billziss at navimatics dot com>]

Hi, Herbert:


On 6/19/16, 1:32 PM, "cygwin-owner@cygwin.com on behalf of Herbert
Stocker" <cygwin-owner@cygwin.com on behalf of hersto@gmx.de> wrote:

>>>G) Case sensitivity.
>>
>> WinFsp (and Windows) allows for both case-sensitive and case-insensitive
>> file systems.
> > <snip>
>> FUSE file systems are marked as case-sensitive by default.
>
>If WinFsp marks FUSE file systems as case-sensitive then there is no
>issue with case sensitiity.
>
>However we should have a look into OSXFUSE, it also has to deal with
>case sensitivity. Let's see how they solved it. There's also MacFUSE
>and Fuse4X according to Wikipedia.

I am familiar with OSXFUSE as my primary development platform is OSX.
OSXFUSE has various extensions to FUSE. In this case a file system can
advertise that it is case insensitive by setting the case_insensitive bit
in fuse_conn_info (passed to fuse_operations::init).

As far as WinFsp-FUSE is concerned I have made it a command line option. I
am happy to change how this is done though and perhaps conform to the
OSXFUSE convention.

>>you would now make those Win32 processes 2nd class citizens,
>> as they would have to go through that intermediate process (which means
>>4
>> context switches per file system request for them).
>
>You are right. I did not think about this extra process. Performance
>wise Win32 processes would be 2nd class. i was just thinking about
>feature wise, where they don't lose.
>
> >>>>>>>
>Now this argument of yours makes me more biased towards mode (3). Let's
>pay with some design unprettiness (remember pipes) and have the better
>performance for both worlds.
>
>And besides, the translations are necessary anyway for mode (2).
>Except for the pipes and hardlinks, they need not be supported in
>mode (2).
>
>best regards,
>as before, i am looking forward to use WinFsp and have FUSE available
>for my Cygwin scripts and stuff. And even for windows processes.

Thanks, Herbert.

In the last few days I have also worked in a mode (3b): a Cygwin package
that contains a cygfuse-2.8.dll that knows how to interface with the rest
of the WinFsp machinery (FSD/DLL).

This makes WinFsp-FUSE usable for a variety of FUSE file systems and
libraries, including language bindings for Python, Perl, etc. For example,
I have a small patch for FUSEPY (Python bindings for FUSE), which
basically defines the Cygwin stat and statvfs structs using Python ctypes.
Other than that FUSEPY just runs. [There are some small issues to be
resolved, but the basis is there.]

The bigger question is whether the Cygwin community would want a package
like this. The obvious answer might be yes (I hope), but there is a large
caveat. WinFsp includes a kernel-mode driver that needs to be built using
Microsoft tools and signed using an EV certificate. In fact it looks like
those requirements will only get harder as time passes -- soon we may need
a sysdev account just to sign drivers. This means that the familiar model
of getting the source and compiling everything using Cygwin tools cannot
work here.

The source code for the cygfuse package can be found below. You will
notice that it is a rather thin layer on top of WinFsp-FUSE implemented in
the WinFsp DLL.

https://github.com/billziss-gh/winfsp/tree/master/opt/cygfuse

Bill