Re: FUSE for Cygwin

Re: FUSE for Cygwin

[Bill Zissimopoulos]

Hi, Herbert:

> > WinFsp provides three (3) different modes of integration:
[snip]
> i'm planning to make a suggestion of mode (4). It will be in addition or
> instead of (3) and will avoid those issues we touched.

I think (based on your earlier ask re: bindings to Python, Perl, etc.) I
may see what you mean with mode (4). Perhaps a libfuse Cygwin DLL that
presents an API *exactly* like the one from FUSE?

Currently WinFsp goes through a number of hoops to support the Win32 and
Cygwin environments with a single DLL. As a result a call to fuse_new is
really a call to fsp_fuse_new through a static inline function.

    static inline struct fuse *fuse_new(...)
    {
        return fsp_fuse_new(fsp_fuse_env(), ...);
    }

Fsp_fuse_env “captures” the environment (e.g. the local malloc/free) so
that the WinFsp DLL can remain environment independent. But this scheme
will not (and cannot) work for e.g. Python bindings that need to dlopen
the “fuse” library. Here is FUSEPY, as example:
    https://github.com/terencehonles/fusepy/blob/master/fuse.py#L66

If that is indeed your plan I would support it.

Creating a libfuse Cygwin DLL like that should be easy. Perhaps I can help
by making the “static inline” part a macro such as FSP_FUSE_STATIC_INLINE,
which one could redefine to __attribute__ ((visibility("default")))

Bill

Re: FUSE for Cygwin

[Herbert Stocker]

Hi Bill,

this is now my proposal of an alternative mode for WinFsp to support
Cygwin based FUSE file systems. I'll call it mode (4).
It's actually my initial idea that i have in mind for some time but
did not propose to implement because i have some constraints that
prevent me from completing it.

Maybe i should first note that i'm not part of Cygwin, i'm just a
user of Cygwin who is happy to have Cygwin. However i know how to
code.

To repeat your 3 modes of operation (in my words):
(1) WinFsp's own API. The file system is a Windows process that
     can use all file system features that Windows (and WinFsp)
     provides.

(2) A FUE API for Win32. The file system is a native Windows process
     but receives requests as defined in fuse.h . It eases porting
     for the file system and does not require Cygwin be installed.

(3) The file system is a Cygwin process and thus can use all POSIX
     features of Cygwin. It needs no porting or only little.

What i don't like on (3) is that when a Cygwin process accesses the
FUSE file system there are two Cygwin processes whose communication
is translated from Posix to Win32 and then back (which is done again
for the response).

You sketched this as follows:
> Let's examine the lifetime of a call to creat(). Suppose a Cygwin process
> does creat("/cygdrive/z/foo*bar"). In the following OP is the "originating
> process", CW is the "Cygwin runtime", NT is NTOS, WD is the "WinFsp FSD",
> WL is the "WinFsp DLL", FL is the "FUSE layer", and FS is the "user mode
> FUSE file system".
>
> OP: creat("/cygdrive/z/foo*bar")
> CW: NtCreateFile(L"<DEVICE>\\foo\xf02abar")     <--- Cygwin translation
> NT: IRP_MJ_CREATE L"\\foo\xf02abar"
> WD: FspFsctlTransactCreateKind L"\\foo\xf02abar"
> WL: FSP_FILE_SYSTEM_INTERFACE::Create L"\\foo\xf02abar"
> FL: fuse_operations::create "/foo*bar"          <--- WinFsp/FUSE
> translation
> FS: somehow satisfies fuse_operations::create
> [snip return path]


So my proposal is basically this:

(4) The file system is a Cygwin process and Cygwin is extended to
     pass file system requests to that process if they fall into the
     respective path (where the file system is mounted.)

     This way the file system is exported to Cygwin only. But another
     tool exports this to the Win32 world.

Initially i thought for the second part we could use that part of
VirtualBox Guest Additions that makes the host file system available
in a windows guest. But now we have WinFsp for this...

For the first part of (4),
Cygwin does have a place that translates Unix paths to Win32 paths.
This part follows the settings in /etc/fstab so that arbitrary Win32
paths can be "mounted" to arbitrary Posix paths with settings applied.
This could be extended so that processes that link to a Cygwin version
of libfuse can register for certain paths.

Cygwin does not have a "kernel", but a Cygwin1.dll which is loaded
into every Cygwin process. On places where it does path lookups or
interferes with files (read, write, extended attributes, etc) it would
require some means to communicate with the file system process and
to wait for the response.

This would make Cygwin processes accessing the file system 1st class
citicens while Windows processes wouldn't lose compared to mode (3).
In mode (3) Cygwin processes would be 2nd class, as i'll explain below.

But the drawback of my approach is that it requires to reimplement
FUSE for Cygwin. If i could, i would volunteer to work on it. i like
Cygwin and i like FUSE, so i sure would like to work on that.

Mode (4) would avoid the following issues coming from the double
translation of mode (3):

A) Besides the double double translations of every request, there
    is also the need for four Kernel/Usermode transitions, which take
    their time.

B) We could have hardlinks for the Cygwin world only, and you have no
    need to implement them in FSD or the DLL. Though you could add that
    feature later not not at all.

    (Or would that be an issue e.g. with oplocs?)

C) i guess this way we could support fuse with all other languages
    besides C/C++.

D) Symlinks won't go through reparse points.
    You'd have no need to implement that or to follow Cygwin should
    Cygwin improve its way of translation.
    BTW, are code pages involved there?

E) Same for uid/gid to SID mapping.
    No need to implement or follow Cygwin.
    And how about the case where a uid/gid has no correspoinding SID?
    Can this happen?

F) Pipes:
 > [Quick experiment:
 >
 > $ mkfifo foo; cmd /c dir 'foo*' | grep foo; rm foo
 > 06/16/2016  11:02 PM               130 foo.lnk
 > ]
 >
 > Ok, so they are shortcuts. Naturally they are supported.

    I think they are not.
    The mkfifo system call will have Cygwin create a .lnk file and
    WinFsp will forward it as such to the file system process. The
    sytem calls readdir or open will then have the file system
    process tell WinFsp that there is a .lnk file and Cygwin will
    translate this back to a fifo, so in this sense it does work.

    But the file system will see a file (with name *.lnk) where it
    should see a pipe (mknod call with 'mode' set to S_IFIFO).
    IMHO one could say this is a break of the FUSE API.

    Practically it will break:
     - file systems that special-treat pipe files (or .lnk files).

     - If one uses sshfs to connect to a Linux based server and
       issues the command mkfifo foo from Cygwin, the server will
       end up with a .lnk file instead of a pipe special file.

     - Imagine something like mysqlfs, which stores the stuff in a
       database. When you run SQL statements to analyze the data
       in the file system, you won't see the pipes as such. Or if
       you open the file system from Linux you'll see the .lnk
       files.

    To fix this with mode (3) you'd have to recognize these .lnk
    files and forward them to the file system as pipes, and you'd
    have to generate .lnk files on the fly when the file system
    says there is a pipe file (e.g. on readdir).

G) Case sensitivity.
    Windows is usually case insensitive but case
    preserving on file names. But there is a registry setting that
    allows one to activate case sensitivity. Then programs that use
    the Win32 API in a certain way can have case sensitivity.
    Cygwin has an option to do so, too. It is an option in the
    /etc/fstab file. (And i use it for all drives.)

    With this you can say   touch a A   in the Cygwin command line
    and you'll see two files in Windows Explorer. Double clicking one
    of them will always open the first file though.

    i guess FUSE file systems ported to mode (3) or (2) will expect
    file names to be case sensitive.
 
https://cygwin.com/cygwin-ug-net/using-specialnames.html#pathnames-casesensitive

    What happens if you use sshfs to connect to a Linux box and then
    do the following in cmd.exe:
      # echo Hallo >Foo.txt
      # type foo.Txt

H) Currently you have either "disk style" file system that you mount
    as a drive letter or a "network style" file sytem that you mount
    via UNC path, e.g. \\sshfs\name@host . Drive letters are a name
    space of only 26 entries which is very narrow, but you can
    also mount them to empty directories on other drives (which must
    support reparse points i think). I don't know if that's possible
    with UNC paths too.

    That means that Cygwin processes will see them as
    //sshfs/name@host and have to use symlinks or /etc/fstab settings
    to "mount" them elsewhere.

It looks like mode (4) is much more work because it requires FUSE
to be reimplemented/ported to Cygwin. But it's lesser work on WinFsp
and would have no issues due to double translations. It would make
Cygwin processes 1st class on FUSE file systems.

So my question is to Corinna, would it be possible and feasible
to implement this in Cygwin?


best regards,

Herbert


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: FUSE for Cygwin

[Bill Zissimopoulos]

Hi, Herbert:


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

>this is now my proposal of an alternative mode for WinFsp to support
>Cygwin based FUSE file systems. I'll call it mode (4)...
>
>To repeat your 3 modes of operation (in my words):...
>
>(3) The file system is a Cygwin process and thus can use all POSIX
>     features of Cygwin. It needs no porting or only little.
>
>What i don't like on (3) is that when a Cygwin process accesses the
>FUSE file system there are two Cygwin processes whose communication
>is translated from Posix to Win32 and then back (which is done again
>for the response).

Actually I do not believe this is the case. Let me show again the complete
path of a creat() request, this time with context switches.

As before in the following OP is the “originating process", CW is the
"Cygwin runtime", NT is NTOS, WD is the "WinFsp FSD”, WL is the "WinFsp
DLL", FL is the "FUSE layer", and FS is the "user mode FUSE file system".

==== RUNNING in OP context
OP: call creat("/cygdrive/z/foo*bar")
CW: call NtCreateFile(L"<DEVICE>\\foo\xf02abar”)
NT: call IRP_MJ_CREATE L"\\foo\xf02abar"
WD: post FspFsctlTransactCreateKind L"\\foo\xf02abar”
==== SWITCH to FS context
WL: recv FspFsctlTransactCreateKind,
    call FSP_FILE_SYSTEM_INTERFACE::Create L"\\foo\xf02abar"
FL: call fuse_operations::create "/foo*bar"
FS: somehow satisfies fuse_operations::create

FS: return errno=0,
    fuse_file_info::fh
FL: return STATUS_SUCCESS,
    FSP_FSCTL_TRANSACT_RSP::Rsp.Create.Opened.UserContext2
WL: return STATUS_SUCCESS,
    FSP_FSCTL_TRANSACT_RSP::Rsp.Create.Opened.UserContext2
WD: complete IRP_MJ_CREATE with
    STATUS_SUCCESS, NTOS FILE_OBJECT properly initialized
==== SWITCH to OP context
NT: return STATUS_SUCCESS,
    HANDLE opened by NTOS for FILE_OBJECT
CW: return fd for HANDLE just opened, (maybe?) set errno=0

As you can see there are only two context switches. The only two processes
involved are OP (the originating process) and FS (the user mode file
system).

[BTW, a WinFsp file system process is able to process multiple requests in
the same thread without a context switch, but from the perspective of an
OP there will be (at least) 2 context switches for a creat() response to
complete.]


>So my proposal is basically this:
>
>(4) The file system is a Cygwin process and Cygwin is extended to
>     pass file system requests to that process if they fall into the
>     respective path (where the file system is mounted.)
>
>     This way the file system is exported to Cygwin only. But another
>     tool exports this to the Win32 world.

It is my understanding from my brief foray into the Cygwin source that
Cygwin already has the fhandler mechanism, which looks like a natural
place to implement a Cygwin-only FUSE for Windows.

>Mode (4) would avoid the following issues coming from the double
>translation of mode (3):
>
>A) Besides the double double translations of every request, there
>    is also the need for four Kernel/Usermode transitions, which take
>    their time.

As explained, there are 2 context switches and not 4. If you had an
fhandler that somehow calls out into a FUSE file system, it would still
need to do 2 context switches (one to get the request to the FUSE file
system and one to get the response back).

The POSIX/Windows translations are actually not that expensive, although
they are not trivial (creating a security descriptor requires memory
allocations). But of course the dominant factor here is the context switch.

>C) i guess this way we could support fuse with all other languages
>    besides C/C++.

BTW, I already had some luck last night getting FUSEPY to work with
WinFsp. I should have something out on this soon.

>E) Same for uid/gid to SID mapping.
>    No need to implement or follow Cygwin.
>    And how about the case where a uid/gid has no correspoinding SID?
>    Can this happen?

Yes, it can, but this is an issue that Cygwin faces itself.

>F) Pipes:
> > [Quick experiment:
> >
> > $ mkfifo foo; cmd /c dir 'foo*' | grep foo; rm foo
> > 06/16/2016  11:02 PM               130 foo.lnk
> > ]
> >
> > Ok, so they are shortcuts. Naturally they are supported.
>
>    I think they are not.
>    The mkfifo system call will have Cygwin create a .lnk file and
>    WinFsp will forward it as such to the file system process. The
>    sytem calls readdir or open will then have the file system
>    process tell WinFsp that there is a .lnk file and Cygwin will
>    translate this back to a fifo, so in this sense it does work.
>
>    But the file system will see a file (with name *.lnk) where it
>    should see a pipe (mknod call with 'mode' set to S_IFIFO).
>    IMHO one could say this is a break of the FUSE API.

Good catch this one!

Of course I can try to fix this in the WinFsp/FUSE layer implementation,
but the fix would probably be a gross and Cygwin-specific hack. But
definitely good catch!

>    To fix this with mode (3) you'd have to recognize these .lnk
>    files and forward them to the file system as pipes, and you'd
>    have to generate .lnk files on the fly when the file system
>    says there is a pipe file (e.g. on readdir).

Yes, I agree. Not pretty!

>G) Case sensitivity.
>    Windows is usually case insensitive but case
>    preserving on file names...
>
>    What happens if you use sshfs to connect to a Linux box and then
>    do the following in cmd.exe:
>      # echo Hallo >Foo.txt
>      # type foo.Txt

WinFsp (and Windows) allows for both case-sensitive and case-insensitive
file systems. I only have OSX currently to SSH into (which is
case-insensitive) so I cannot run your experiment. But I expect that the
"type" command would not work, because FUSE file systems are marked as
case-sensitive by default (or I have a bug in WinFsp).

>It looks like mode (4) is much more work because it requires FUSE
>to be reimplemented/ported to Cygwin. But it's lesser work on WinFsp
>and would have no issues due to double translations. It would make
>Cygwin processes 1st class on FUSE file systems.

Just to clarify: I believe that Cygwin processes are already on the same
class as Win32 processes when it comes to a WinFsp exposed file system.
There are no extra context switches and the only translations required are
those that Cygwin does for its POSIX layer and against the existing
Windows file systems (like NTFS).

IMO getting a FUSE for (just) Cygwin should be relatively easy using the
fhandler mechanism (disclaimer: I am no expert in the Cygwin source and
have probably spent a total of an hour or two on it). IMO it would also be
desirable.

OTOH you would also lose the ability to easily port FUSE file systems to
*all* of Windows, which (at least for me) has been the primary reason for
doing this work. Even if you created an intermediate Cygwin process (that
acted as a WinFsp file system) to let Win32 processes access these FUSE
file systems, 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).

Bill

Re: FUSE for Cygwin

[Herbert Stocker]

Hi Bill,

i agree with you that there are only two context switches involved
and that Cygwin processes are not 2nd class performance.

But i was *not* talking about context switches.
i was talking about *translating of semantics* mostly in my mail.

Because i was trying to avoid translation from Posix to Win32
*and back*, just to go from Cygwin process to Cygwin process.

And the reason i want to avoid the translations is not performance.
It is because mode (4) does not have those issues that WinFsp must
take care of in (3). See my points B) to G).

Please also see the end of this mail, i overlooked something you did
not. So i'm now more biased towards (3).


Now some specific answers:
 >> E) Same for uid/gid to SID mapping.
 >>    No need to implement or follow Cygwin.
 >>    And how about the case where a uid/gid has no correspoinding SID?
 >>    Can this happen?
 >
 > Yes, it can, but this is an issue that Cygwin faces itself.
 >
It will not face it if communication between both Cygwin processes
does not leave Posix semantics. See what i try to avoid?


 >> F) Pipes:
 >
 > Good catch this one!
 >
 > Of course I can try to fix this in the WinFsp/FUSE layer
 > implementation, but the fix would probably be a gross and
 > Cygwin-specific hack.

Mode (4) would avoid such things *by design*.
Not because we happen to catch all of them.


>> To fix this with mode (3) you'd have to recognize these .lnk
>>    files and forward them to the file system as pipes, and you'd
>>    have to generate .lnk files on the fly when the file system
>>    says there is a pipe file (e.g. on readdir).
>
> Yes, I agree. Not pretty!
>
But please do that if you stay with mode (3).


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



> Just to clarify: I believe that Cygwin processes are already on the same
> class as Win32 processes when it comes to a WinFsp exposed file system.
> There are no extra context switches

Context switch wise they are the same class. But i was not concerned
about context switches.

> Even if you created an intermediate Cygwin process (that
> acted as a WinFsp file system) to let Win32 processes access these FUSE
> file systems,

That was defintively my aim. And i think we should use WinFsp for that.

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

Herbert




--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: FUSE for Cygwin

[Bill Zissimopoulos]

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

Re: FUSE for Cygwin

[Jeffrey Altman]

[-- Attachment #1: Type: text/plain, Size: 875 bytes --]

On 6/22/2016 3:43 PM, Bill Zissimopoulos wrote:
>
> 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.

I believe that as of Windows 10 Anniversary Edition and Server 2016
Secure Boot becomes mandatory for new installations and with Secure Boot
comes the requirement that all device drivers (including file system
drivers) be signed by Microsoft.

Jeffrey Altman



[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4349 bytes --]

Re: FUSE for Cygwin

[Bill Zissimopoulos]

On 6/22/16, 1:39 PM, "Jeffrey Altman" <cygwin-owner@cygwin.com on behalf
of jaltman@secure-endpoints.com> wrote:


>On 6/22/2016 3:43 PM, Bill Zissimopoulos wrote:
>>
>> 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.
>
>I believe that as of Windows 10 Anniversary Edition and Server 2016
>Secure Boot becomes mandatory for new installations and with Secure Boot
>comes the requirement that all device drivers (including file system
>drivers) be signed by Microsoft.

I agree. That is my understanding as well.

Bill

Re: FUSE for Cygwin

[Bill Zissimopoulos]

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


>What i don't like on (3) is that when a Cygwin process accesses the
>FUSE file system there are two Cygwin processes whose communication
>is translated from Posix to Win32 and then back (which is done again
>for the response).
[snip]
>A) Besides the double double translations of every request, there
>    is also the need for four Kernel/Usermode transitions, which take
>    their time.

By the way Herbert in re-reading your email, you may *not* have meant to
say that in the current WinFsp/FUSE scheme there are 4 *context switches*
(instead of 2), in which case my apologies for trying to explain something
you already were aware of.


Bill

FUSE for Cygwin - was: Re: Fork and Windows Heap

[Bill Zissimopoulos]

[I apologize if my responses to the list appear to break the mailing list's
threading model. I am not actually subscribed to the list and I respond to
individual messages using my mail app.]

Hello, Herbert:

Herbert Stocker wrote:
> > On 16.06.2016 08:37, Bill Zissimopoulos wrote:
> >
> > I have a Windows solution developed using Visual Studio
> > and the Windows Driver Kit that I am building a FUSE
> > compatibility layer for.
> 
> this is a GREAT piece of work.
> Although i did not dive into kernel development, i do understand that
> writing a file system driver for Windows is surely lots of painful work,
> with its undocumented and grown API.
>
> You should write a book documenting all the knowledge you gathered
> through your research, if the only one available is from '97 as you say.
>
> Really, great work.
> Also that you add the FUSE API.

Thank you for your very kind words.

> So, how is your architecture of the FUSE part of WinFsp?
> Are you porting libfuse to Cygwin, so that a Cygwin process can link to
> it and instead of receiving requests via /dev/fuse fro the Linux kernel,
> your libfuse will receive IRPs through your user mode DLL from your
> Windows kernel driver FSD?

WinFsp consists of a kernel-mode file system driver (FSD) and a user mode
dynamic link library (DLL). The FSD registers two devices in the NTOS
(Windows
kernel) namespace with names: \Device\WinFsp.Disk and \Device\WinFsp.Net.
The
DLL interacts with these devices using CreateFile and DeviceIoControl.

The FSD receives IRP's by the kernel and if it cannot handle them itself,
it
posts them to an I/O queue. At a later time the user mode file system
process
receives the IRP's from the queue using DeviceIoControl. The user mode file
system handles the IRP's and then send the responses back to the FSD, which
then completes the IRP's.

All this is of course nicely wrapped by an API so that the user-mode file
system developer never sees IRP's. Instead IRP's are translated to callback
calls with familiar names and semantics such as Create, Open, Read, Write,
etc.

The FUSE layer is a thin layer on top of this api. For example, the WinFsp
Create callback maps to FUSE mkdir or create, the Open callback maps to
FUSE
opendir or open, etc.

I am not porting libfuse to Windows. This is a complete reimplementation.

For the full details on the WinFsp design please see this document:
    http://www.secfs.net/winfsp/develop/design/

For details on the FUSE port please see the WinFsp blog:
    http://www.secfs.net/winfsp/blog/

> Are you planning to have FUSE file systems be ported to native Windows
> apps, i.e. don't link with cygwin1.dll, or will they run in a Cygwin
> environment?

WinFsp provides three (3) different modes of integration:

(1) Its own native API, which allows a user mode file system to do almost
anything NTFS can do (with a few exceptions). It also allows for the
Read, Write and ReadDirectory callbacks to be asynchronous (return
STATUS_PENDING). I recommend this API for file systems that want maximum
performance and integration with Windows.

(2) A FUSE (high-level) API for Win32 (i.e. non-Cygwin) applications. This
is useful if one has a FUSE file system that they can easily port to
Windows or they do not want any Cygwin dependencies.

(3) A FUSE (high-level) API for Cygwin. As you correctly note many FUSE
file systems are too POSIX specific (as they were born on Linux/OSX) and
they only make sense in a Cygwin environment.

I expect that most FUSE file systems will probably go for option (3)
initially. Then they may want to consider going to (2) if they can
easily port their core file system code to Windows. Then they may even
consider (1) if they have needs that the FUSE API cannot support (e.g.
full support for Windows ACL's).

> If porting to native app, this would be easier for the user to install
> them, but:
>  - FUSE has bindings to many languages like Perl, PHP, etc. Will these
>    work then?

I expect that parts of the bindings will have to be rewritten. WinFsp does
not pretend to be FUSE, it only has a FUSE API for someone that writes C
or C++ and has a compiler that understands #include <fuse.h>

> How are you dealing with limitations of the Windows file system as seen
> from a POSIX perspective? You say you can't support hard links.

Windows hard links are rather un-POSIX like and rarely used on Windows.
After considering the required changes on the FSD for a feature that is
so rarely used I opted against supporting them.

I expect that POSIX file systems with hard link support need to take some
care when exposed through WinFsp. But I admit that I have not thought too
hard about this problem and I do not have any solid recommendations or
solutions at this point.

> How will a Cygwin program see symlinks exported by the FUSE file system?

WinFsp will present symlinks as reparse points. Cygwin already knows how
to deal with NTFS reparse points and it will present them as POSIX
symlinks.
I may even relax the whole “you have to be admin to create a symlink”
nonsense.

Please note that WinFsp does (not) yet support reparse points. There is no
big obstacle in the way, just a question of time.

> And pipes?

Pipes in Windows are not stored in the file system, rather they are
implemented by a special Windows file system called NPFS. OTOH POSIX
FIFO's are special files. I am unsure at this time how Cygwin represents
FIFO's.

[Quick experiment:

$ mkfifo foo; cmd /c dir 'foo*' | grep foo; rm foo
06/16/2016  11:02 PM               130 foo.lnk
]

Ok, so they are shortcuts. Naturally they are supported.

> You write that you are mapping
>  - characters not supported by Win32 but by POSIX via the Unicode
>    private use page
>  - Security apspects (SID vs. uid/gid, ACL)
> between POSIX and Windows and that you do it like Cygwin/SFU/SFM is
> doing it.
>
> But if that's done by your code, a Cygwin process may see slightly
> different mappings through WinFsp and through Cygwin. Won't that be a
> potential for Bugs (misbehaving apps) or even for security issues?

I agree that the potential is there. But I did not want WinFsp to depend
on Cygwin so reimplementation was the best option for me. Additionally
Cygwin does not expose this functionality to third party apps AFAIK.

> i'm looking forward to trying it out this weekend and to see it go
> from alpha state to stable.

Thank you for your support :)

> (And i'm curious about the differences of disk based and network based
> file systems. Is it just the handling as seen from the user or also
> the semantics.)

The main difference is how "mounting" happens. Also the Windows explorer
provides different behavior for a disk and network file system. The actual
user mode file system sees no difference whether it is mounted as a disk
or a network file system.

Ok, a quick primer on "mounting" on Windows.

A file system is implemented as a special device that is unnamed (i.e.
does not have a name in the NTOS namespace). Nevertheless this file system
device must somehow receive file system related requests. This is done by
associating (mounting) this device with either a disk device (e.g.
a hard drive) or with the MUP (Multiple UNC Provider).

When the file system device gets associated with a disk device it becomes
a disk file system. When it gets associated with the MUP it becomes a
network file system.

Usually we assign a drive letter X: to a new file system and that is how
we access files on it. But with MUP there is another option: using the
\\Server\Share notation. This is the first important difference between
a disk and network file system.

[There is actually another option for accessing files on a file system.

Try this from a cmd.exe prompt:
    type \\?\GLOBALROOT\Device\HarddiskVolume2\Cygwin64\Cygwin.bat

This assumes that your C: drive points to \Device\HarddiskVolume2 and
that you have Cygwin installed under C:\Cygwin64.]

The second important difference between disk and network file systems
is Windows Explorer support. Windows explorer allows you to map
network drives, list them, etc.

I am using this with WinFsp to spawn file system instances straight
from explorer. For example mapping the network drive Z: to
\\sshfs\billziss@myhost will spawn a new instance of SSHFS that
connects to billziss@myhost. [Please note that while WinFsp already
implements this support, my SSHFS port is not there yet.]

For this reason alone, I expect that most user mode file systems
will be packaged to work as network file systems.

Bill

Re: FUSE for Cygwin

[Herbert Stocker]

On 6/17/2016 9:25 AM, Bill Zissimopoulos wrote:
> WinFsp provides three (3) different modes of integration:
>
> (1) Its own native API, which allows a user mode file system to do almost
> anything NTFS can do (with a few exceptions). It also allows for the
> Read, Write and ReadDirectory callbacks to be asynchronous (return
> STATUS_PENDING). I recommend this API for file systems that want maximum
> performance and integration with Windows.
>
> (2) A FUSE (high-level) API for Win32 (i.e. non-Cygwin) applications. This
> is useful if one has a FUSE file system that they can easily port to
> Windows or they do not want any Cygwin dependencies.
>
> (3) A FUSE (high-level) API for Cygwin. As you correctly note many FUSE
> file systems are too POSIX specific (as they were born on Linux/OSX) and
> they only make sense in a Cygwin environment.
>
> I expect that most FUSE file systems will probably go for option (3)
> initially. Then they may want to consider going to (2) if they can
> easily port their core file system code to Windows. Then they may even
> consider (1) if they have needs that the FUSE API cannot support (e.g.
> full support for Windows ACL's).

Hi Bill,

i'm planning to make a suggestion of mode (4). It will be in addition or
instead of (3) and will avoid those issues we touched.
But i can't do it earlier than Saturday evening.

Of course i did read your website before posting this, don't know why i
asked that question about your design this way though.

Herbert



--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple