[ITP] FUSE 2.8

[ITP] FUSE 2.8

[Bill Zissimopoulos]

This package adds FUSE 2.8 support to Cygwin. FUSE is the well-known
"Filesystem in Userspace" project for Linux and other platforms: [FUSE].

FUSE file systems that use this package usually require minimal changes to
run on Cygwin. For example, here are the pull requests I have submitted to
SSHFS and FUSEPY to make them run on Cygwin: [SSHFS-PR], [FUSEPY-PR].

FUSE file systems that use this package will expose a file system not just
to Cygwin, but to ALL of Windows (i.e. Explorer, cmd.exe and all of
Windows apps will be able to access their files). For this to work the
cygfuse.dll in the package needs to interface with a kernel mode
component, which does NOT ship as part of this package.

Which brings me to a large caveat with this package. The package has an
external dependency on my own open source project called WinFsp [WINFSP].
WinFsp includes the necessary kernel-mode driver that enables the
FUSE-like functionality on Windows. Unfortunately this driver can only be
built with Microsoft tools. Furthermore it must be signed with an EV
certificate (and going forward Microsoft will soon require that they sign
every kernel mode driver themselves through the sysdev portal).

For this reason you cannot simply get the source code for the FUSE cygport
and WinFsp and compile everything from scratch. This is not a licensing
issue (all code is AGPLv3), but a tools/signing issue. The alternatives
are:

1. Accept the FUSE cygport package as is. Understand that it requires
prior installation of WinFsp in order to properly work.

2. Accept the FUSE cygport package, but require that the package downloads
and installs the WinFsp MSI (perhaps as part of its post install process).

3. Reject this package.

I have currently implemented option (1) but I am happy to change to option
(2). The package files can be found at [CYGFUSE]. The source code for the
package can be found under the opt/cygfuse directory in this repository:
[WINFSP-GH]

The setup.hint file is as follows:

    category: Utils
    requires: cygwin pkg-config
    sdesc: "WinFsp-FUSE compatibility layer"
    ldesc: "WinFsp-FUSE enables FUSE file systems to be run on Cygwin."

The package is generated by the following cygport file:

    NAME="fuse"
    VERSION=2.8
    RELEASE=3
    CATEGORY="Utils"
    SUMMARY="WinFsp-FUSE compatibility layer"
    DESCRIPTION="WinFsp-FUSE enables FUSE file systems to be run on
Cygwin."
    HOMEPAGE="http://www.secfs.net/winfsp/"

    
SRC_URI=${CYGPORT_SRC_URI:-"https://github.com/billziss-gh/winfsp/archive/m
aster.tar.gz"}
    SRC_DIR=${CYGPORT_SRC_DIR:-winfsp-master}

    src_compile()
    {
        lndirs
        cd ${B}/opt/cygfuse
        make
     }

    src_install()
    {
        cd ${B}/inc/fuse
        includeinto fuse
        doinclude fuse.h
        doinclude fuse_common.h
        doinclude fuse_opt.h
        doinclude winfsp_fuse.h

        cd ${B}/opt/cygfuse
        dobin cygfuse-${VERSION}.dll
        dolib libfuse-${VERSION}.dll.a
        dosym libfuse-${VERSION}.dll.a /usr/lib/libfuse.dll.a
        dopkgconfig fuse.pc
    }

    RESTRICT="strip postinst-doc"

To test the package install it and the WinFsp MSI. Also install glib2 and
any build tools you may be missing. Clone my fork of SSHFS from [SSHFS].
Then issue the following commands in the cloned repository.

    autoreconf -i
    ./configure
    make

You should now be able to test sshfs with a command line such as:

    ./sshfs -o idmap=user billziss@macbook-pro: Y:

Be sure to issue this command from a non-administrator prompt as Windows
has some arcane rules on how drives are assigned. You can now open Windows
explorer and browse through drive Y:. When you are done simply issue:

    pkill sshfs

Comments greatly appreciated.

Bill

[CYGFUSE]   https://github.com/billziss-gh/winfsp/releases/tag/v0.14
[FUSE]      https://en.wikipedia.org/wiki/Filesystem_in_Userspace
[FUSEPY-PR] https://github.com/terencehonles/fusepy/pull/54
[SSHFS]     https://github.com/billziss-gh/sshfs
[SSHFS-PR]  https://github.com/libfuse/sshfs/pull/23
[WINFSP]    http://www.secfs.net/winfsp/
[WINFSP-GH] https://github.com/billziss-gh/winfsp

Re: [ITP] FUSE 2.8

[David Stacey]

On 17/07/16 02:02, Bill Zissimopoulos wrote:
> The package has an
> external dependency on my own open source project called WinFsp [WINFSP].
> WinFsp includes the necessary kernel-mode driver that enables the
> FUSE-like functionality on Windows. Unfortunately this driver can only be
> built with Microsoft tools. Furthermore it must be signed with an EV
> certificate (and going forward Microsoft will soon require that they sign
> every kernel mode driver themselves through the sysdev portal).
>
> For this reason you cannot simply get the source code for the FUSE cygport
> and WinFsp and compile everything from scratch. This is not a licensing
> issue (all code is AGPLv3), but a tools/signing issue.


IIRC, there is already precedent for this sort of thing in the Linux 
world, as boot loaders need to be signed to work with UFEI Secure Boot - 
see [1].

Dave.

[1] - https://fedoraproject.org/wiki/Secureboot

Re: [ITP] FUSE 2.8

[Marco Atzeri]

On 17/07/2016 03:02, Bill Zissimopoulos wrote:
> This package adds FUSE 2.8 support to Cygwin. FUSE is the well-known
> "Filesystem in Userspace" project for Linux and other platforms: [FUSE].
>
> FUSE file systems that use this package usually require minimal changes to
> run on Cygwin. For example, here are the pull requests I have submitted to
> SSHFS and FUSEPY to make them run on Cygwin: [SSHFS-PR], [FUSEPY-PR].
>
> FUSE file systems that use this package will expose a file system not just
> to Cygwin, but to ALL of Windows (i.e. Explorer, cmd.exe and all of
> Windows apps will be able to access their files). For this to work the
> cygfuse.dll in the package needs to interface with a kernel mode
> component, which does NOT ship as part of this package.
>
> Which brings me to a large caveat with this package. The package has an
> external dependency on my own open source project called WinFsp [WINFSP].
> WinFsp includes the necessary kernel-mode driver that enables the
> FUSE-like functionality on Windows. Unfortunately this driver can only be
> built with Microsoft tools. Furthermore it must be signed with an EV
> certificate (and going forward Microsoft will soon require that they sign
> every kernel mode driver themselves through the sysdev portal).
>
> For this reason you cannot simply get the source code for the FUSE cygport
> and WinFsp and compile everything from scratch. This is not a licensing
> issue (all code is AGPLv3), but a tools/signing issue. The alternatives
> are:
>
> 1. Accept the FUSE cygport package as is. Understand that it requires
> prior installation of WinFsp in order to properly work.

libusb0 has similar requirements

Extract from the setup.ini
-------------------------------------------------------------------
message: libusb0 "In order to use libusb0, you must download and run the
LibUSB-Win32 driver installer from:
https://sourceforge.net/projects/libusb-win32/files/libusb-win32-releases/1.2.6.0/libusb-win32-devel-filter-1.2.6.0.exe"
---------------------------------------------------------------------

similar  mDNSResponder and avahi.

> 2. Accept the FUSE cygport package, but require that the package downloads
> and installs the WinFsp MSI (perhaps as part of its post install process).

That will be complicated, I prefer #1

>
> 3. Reject this package.
>
> I have currently implemented option (1) but I am happy to change to option
> (2). The package files can be found at [CYGFUSE]. The source code for the
> package can be found under the opt/cygfuse directory in this repository:
> [WINFSP-GH]
>
>
>     pkill sshfs
>
> Comments greatly appreciated.
>
> Bill

Regards
Marco

Re: [ITP] FUSE 2.8

[Bill Zissimopoulos]

On 7/17/16, 2:18 PM, Marco Atzeri wrote:

>On 17/07/2016 03:02, Bill Zissimopoulos wrote:
>> This package adds FUSE 2.8 support to Cygwin. FUSE is the well-known
>> "Filesystem in Userspace" project for Linux and other platforms: [FUSE].
>>
>>[snip]
>>
>> Which brings me to a large caveat with this package. The package has an
>> external dependency on my own open source project called WinFsp
>>[WINFSP].
>
>libusb0 has similar requirements
>
>Extract from the setup.ini
>-------------------------------------------------------------------
>message: libusb0 "In order to use libusb0, you must download and run the
>LibUSB-Win32 driver installer from:
>https://sourceforge.net/projects/libusb-win32/files/libusb-win32-releases/
>1.2.6.0/libusb-win32-devel-filter-1.2.6.0.exe"
>---------------------------------------------------------------------
>
>similar  mDNSResponder and avahi.

Great. It is good to know that this is not as large a caveat as I thought
it was.

>> 2. Accept the FUSE cygport package, but require that the package
>>downloads
>> and installs the WinFsp MSI (perhaps as part of its post install
>>process).
>
>That will be complicated, I prefer #1

I also prefer #1.

Bill

Re: [ITP] FUSE 2.8

[Corinna Vinschen]

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

On Jul 17 01:02, Bill Zissimopoulos wrote:
> This package adds FUSE 2.8 support to Cygwin. FUSE is the well-known
> "Filesystem in Userspace" project for Linux and other platforms: [FUSE].
> 
> FUSE file systems that use this package usually require minimal changes to
> run on Cygwin. For example, here are the pull requests I have submitted to
> SSHFS and FUSEPY to make them run on Cygwin: [SSHFS-PR], [FUSEPY-PR].
> 
> FUSE file systems that use this package will expose a file system not just
> to Cygwin, but to ALL of Windows (i.e. Explorer, cmd.exe and all of
> Windows apps will be able to access their files). For this to work the
> cygfuse.dll in the package needs to interface with a kernel mode
> component, which does NOT ship as part of this package.
> 
> Which brings me to a large caveat with this package. The package has an
> external dependency on my own open source project called WinFsp [WINFSP].
> WinFsp includes the necessary kernel-mode driver that enables the
> FUSE-like functionality on Windows. Unfortunately this driver can only be
> built with Microsoft tools. Furthermore it must be signed with an EV
> certificate (and going forward Microsoft will soon require that they sign
> every kernel mode driver themselves through the sysdev portal).
> 
> For this reason you cannot simply get the source code for the FUSE cygport
> and WinFsp and compile everything from scratch. This is not a licensing
> issue (all code is AGPLv3), but a tools/signing issue. The alternatives
> are:
> 
> 1. Accept the FUSE cygport package as is. Understand that it requires
> prior installation of WinFsp in order to properly work.
> 
> 2. Accept the FUSE cygport package, but require that the package downloads
> and installs the WinFsp MSI (perhaps as part of its post install process).
> 
> 3. Reject this package.
> 
> I have currently implemented option (1) but I am happy to change to option
> (2). The package files can be found at [CYGFUSE]. The source code for the
> package can be found under the opt/cygfuse directory in this repository:
> [WINFSP-GH]

I'm ok with whatever you guys come up with (baring licensing requirements).
Just one comment:

Bill, you're aware that the code for the "nobody" handling is not yet in
the Cygwin git repo?  If your code requires the patch, it won't work
with current Cygwin 2.5.2, nor with any developer snapshot.

Btw., I didn't apply it yet because I was still waiting for a mailing
list reply to https://cygwin.com/ml/cygwin/2016-06/msg00460.html
On second thought, this didn't look like a question, much.  So, what do
you prefer?

  "WinFSP+nobody"
  "nodomain+nobody"
  "no+body"

Personally I like the third variation but I'm not religious about it.


Thanks,
Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [ITP] FUSE 2.8

[Bill Zissimopoulos]

On 7/18/16, 1:19 AM, Corinna Vinschen wrote:


>On Jul 17 01:02, Bill Zissimopoulos wrote:
>>The alternatives are:
>> 
>> 1. Accept the FUSE cygport package as is. Understand that it requires
>> prior installation of WinFsp in order to properly work.
>> 
>> 2. Accept the FUSE cygport package, but require that the package
>>downloads
>> and installs the WinFsp MSI (perhaps as part of its post install
>>process).
>> 
>> 3. Reject this package.
>> 
>> I have currently implemented option (1) but I am happy to change to
>>option
>> (2). The package files can be found at [CYGFUSE]. The source code for
>>the
>> package can be found under the opt/cygfuse directory in this repository:
>> [WINFSP-GH]
>
>I'm ok with whatever you guys come up with (baring licensing
>requirements).

Thanks, Corinna. I am in favor of option #1 and if the package gets
blessed I will be happy to maintain it.

>Just one comment:
>
>Bill, you're aware that the code for the "nobody" handling is not yet in
>the Cygwin git repo?  If your code requires the patch, it won't work
>with current Cygwin 2.5.2, nor with any developer snapshot.

WinFsp implements the agreed upon mapping (S-1-0-65534 <-> 65534). Cygwin
does not implement the mapping yet, which effectively means that 65534
gets mapped to -1 (Unknown+User, Unknown+Group). Here is a mini-session
with SSHFS with mapping and not mapping the local user to the remote user.

    $ ./sshfs -p PORT USER@HOST: Y:
    USER@HOST's password:
    $ ls -la /cygdrive/y
    total 16
    dr-xr-xr-x 1 Unknown+User Unknown+Group  0 Jul 15 16:49 .
    dr-xr-xr-x 1 billziss     None           0 Jul 18 12:26 ..
    -r--r--r-- 1 Unknown+User Unknown+Group 15 Jun 23 23:57 Foo.txt
    ---------- 1 Unknown+User Unknown+Group 15 Jul 15 16:48 HelloWorld.txt
    d--------- 1 Unknown+User Unknown+Group  0 Jul 15 16:49 opt
    $ pkill sshfs
    $ ./sshfs -o idmap=user -p PORT USER@HOST: Y:
    USER@HOST's password:
    $ ls -la /cygdrive/y
    total 16
    drwxr-xr-x 1 billziss Unknown+Group  0 Jul 15 16:49 .
    dr-xr-xr-x 1 billziss None           0 Jul 18 12:27 ..
    -rw-r--r-- 1 billziss Unknown+Group 15 Jun 23 23:57 Foo.txt
    -rwx------ 1 billziss Unknown+Group 15 Jul 15 16:48 HelloWorld.txt
    drwx------ 1 billziss Unknown+Group  0 Jul 15 16:49 opt
    $ pkill sshfs

>Btw., I didn't apply it yet because I was still waiting for a mailing
>list reply to https://cygwin.com/ml/cygwin/2016-06/msg00460.html
>On second thought, this didn't look like a question, much.  So, what do
>you prefer?
>
>  "WinFSP+nobody"
>  "nodomain+nobody"
>  "no+body"
>
>Personally I like the third variation but I'm not religious about it.

My apologies. I did not understand that you were waiting on an answer from
me.

My preference is for nodomain+nobody, primarily because the individual
components “nodomain”, “nobody” describe the lack of domain and username
when read in isolation (i.e. not in the construction nodomain+nobody). But
WinFsp does not use these names (only the SID’s/UID’s) and you, Corinna,
as the Cygwin lead are more qualified than me to choose what fits Cygwin
best.

Many thanks!

Bill

Re: [ITP] FUSE 2.8

[Bill Zissimopoulos]

On 7/18/16, 12:43 PM, Bill Zissimopoulos wrote:


>On 7/18/16, 1:19 AM, Corinna Vinschen wrote:
>
>>Btw., I didn't apply it yet because I was still waiting for a mailing
>>list reply to https://cygwin.com/ml/cygwin/2016-06/msg00460.html
>>On second thought, this didn't look like a question, much.  So, what do
>>you prefer?
>>
>>  "WinFSP+nobody"
>>  "nodomain+nobody"
>>  "no+body"
>>
>>Personally I like the third variation but I'm not religious about it.
>
>My preference is for nodomain+nobody, primarily because the individual
>components “nodomain”, “nobody” describe the lack of domain and username
>when read in isolation (i.e. not in the construction nodomain+nobody). But
>WinFsp does not use these names (only the SID’s/UID’s) and you, Corinna,
>as the Cygwin lead are more qualified than me to choose what fits Cygwin
>best.

BTW, I now note that no+body is more inline with the existing practice of
"Unknown+User”. I assumed that the parts of the “no+body” construction can
be found in isolation (resulting in a domain of “no” and a user name of
“body”), but perhaps this is not possible. Either way I am happy with
whatever you choose.

Bill

Re: [ITP] FUSE 2.8

[Corinna Vinschen]

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

On Jul 18 19:51, Bill Zissimopoulos wrote:
> On 7/18/16, 12:43 PM, Bill Zissimopoulos wrote:
> 
> 
> >On 7/18/16, 1:19 AM, Corinna Vinschen wrote:
> >
> >>Btw., I didn't apply it yet because I was still waiting for a mailing
> >>list reply to https://cygwin.com/ml/cygwin/2016-06/msg00460.html
> >>On second thought, this didn't look like a question, much.  So, what do
> >>you prefer?
> >>
> >>  "WinFSP+nobody"
> >>  "nodomain+nobody"
> >>  "no+body"
> >>
> >>Personally I like the third variation but I'm not religious about it.
> >
> >My preference is for nodomain+nobody, primarily because the individual
> >components “nodomain”, “nobody” describe the lack of domain and username
> >when read in isolation (i.e. not in the construction nodomain+nobody). But
> >WinFsp does not use these names (only the SID’s/UID’s) and you, Corinna,
> >as the Cygwin lead are more qualified than me to choose what fits Cygwin
> >best.
> 
> BTW, I now note that no+body is more inline with the existing practice of
> "Unknown+User”. I assumed that the parts of the “no+body” construction can
> be found in isolation (resulting in a domain of “no” and a user name of
> “body”), but perhaps this is not possible. Either way I am happy with
> whatever you choose.

Let's just try how it looks like.  I applied the patch using
"nodomain+nobody" for now and uploaded a developer snapshot to
https://cygwin.com/snapshots/

Please take a look.


Thanks,
Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [ITP] FUSE 2.8

[Bill Zissimopoulos]

On 7/19/16, 2:41 AM, Corinna Vinschen wrote:

>
>Let's just try how it looks like.  I applied the patch using
>"nodomain+nobody" for now and uploaded a developer snapshot to
>https://cygwin.com/snapshots/

Hi, Corinna:

Here is simple SSHFS output with the patched cygwin1.dll:

    billziss@windows:/cygdrive/y$ ls -l
    total 12
    -r--r--r-- 1 nodomain+nobody nodomain+nobody 15 Jun 23 23:57 Foo.txt
    ---------- 1 nodomain+nobody nodomain+nobody 15 Jul 15 16:48
HelloWorld.txt
    d--------- 1 nodomain+nobody nodomain+nobody  0 Jul 15 16:49 opt

And here are the actual permissions reported to the OS (and Cygwin):

    billziss@windows:/cygdrive/y$ for f in *; do cacls $f /S; done
    Y:\Foo.txt 
"D:P(A;;0x1f0199;;;S-1-0-65534)(A;;FR;;;S-1-0-65534)(A;;FR;;;WD)"

    Y:\HelloWorld.txt
"D:P(A;;0x1f0198;;;S-1-0-65534)(A;;0x120088;;;S-1-0-65534)(A;;0x120088;;;WD
)"

    Y:\opt 
"D:P(A;;0x1f0198;;;S-1-0-65534)(A;;0x120088;;;S-1-0-65534)(A;;0x120088;;;WD
)"

You will note that nodomain+nobody is used for both user and group. Which
my understanding is that it is legal in Windows. [I note however that
Cygwin is able to distinguish between Unknown+User and Unknown+Group.]


Let me know what you think.

Bill

Re: [ITP] FUSE 2.8

[Corinna Vinschen]

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

On Jul 19 17:26, Bill Zissimopoulos wrote:
> On 7/19/16, 2:41 AM, Corinna Vinschen wrote:
> 
> >
> >Let's just try how it looks like.  I applied the patch using
> >"nodomain+nobody" for now and uploaded a developer snapshot to
> >https://cygwin.com/snapshots/
> 
> Hi, Corinna:
> 
> Here is simple SSHFS output with the patched cygwin1.dll:
> 
>     billziss@windows:/cygdrive/y$ ls -l
>     total 12
>     -r--r--r-- 1 nodomain+nobody nodomain+nobody 15 Jun 23 23:57 Foo.txt
>     ---------- 1 nodomain+nobody nodomain+nobody 15 Jul 15 16:48
> HelloWorld.txt
>     d--------- 1 nodomain+nobody nodomain+nobody  0 Jul 15 16:49 opt
> 
> And here are the actual permissions reported to the OS (and Cygwin):
> 
>     billziss@windows:/cygdrive/y$ for f in *; do cacls $f /S; done
>     Y:\Foo.txt 
> "D:P(A;;0x1f0199;;;S-1-0-65534)(A;;FR;;;S-1-0-65534)(A;;FR;;;WD)"
> 
>     Y:\HelloWorld.txt
> "D:P(A;;0x1f0198;;;S-1-0-65534)(A;;0x120088;;;S-1-0-65534)(A;;0x120088;;;WD
> )"
> 
>     Y:\opt 
> "D:P(A;;0x1f0198;;;S-1-0-65534)(A;;0x120088;;;S-1-0-65534)(A;;0x120088;;;WD
> )"
> 
> You will note that nodomain+nobody is used for both user and group. Which
> my understanding is that it is legal in Windows. [I note however that
> Cygwin is able to distinguish between Unknown+User and Unknown+Group.]

There's a difference.  Unknown+User/Unknown+Group are just
unidirectional fakes for SIDs the Windows functions can't resolve at
all.  There's no way to convert the username "Unknown+User" back to a
valid SID since all unknown SIDs are subsumed under Unknown+User with
uid -1.

OTOH, "nodomain+nobody" has a valid SID, at least in our self-defined
realm.  So Cygwin gets the same S-1-0-65534 SID for both, user and
group.  Since it has the same SID, it's the same account.

For all practical purposes that should work out fine.  You know
what to do with the SID on your side, Cygwin knows what to do with
the SID on its side,

Windows... not so, but since it's the same SID it is the same account
from Windows' perspective as well.

We just might still want to change the name to "no+body".

What do others on this list think?  What sounds better?

 "nodomain+nobody" or "no+body"

?


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [ITP] FUSE 2.8

[Bill Zissimopoulos]

On 7/20/16, 1:52 AM, Corinna Vinschen wrote:

>We just might still want to change the name to "no+body".
>
>What do others on this list think?  What sounds better?
>
> "nodomain+nobody" or "no+body"

Corinna, hi.

I know you have asked others to chime in, but IMO you should go ahead and
change it to “no+body”.

I also would ask others to chime in regarding this package and
specifically if it is one they would like to see in Cygwin.

I am also unclear on what the next steps are regarding this package
submission. Does the package need 5 votes in order to be accepted? Does it
only need 1 GTG vote because FUSE packages already exist on most major
Linux distros?

Thanks.

Bill

Re: [ITP] FUSE 2.8

[Corinna Vinschen]

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

On Jul 21 22:11, Bill Zissimopoulos wrote:
> On 7/20/16, 1:52 AM, Corinna Vinschen wrote:
> 
> >We just might still want to change the name to "no+body".
> >
> >What do others on this list think?  What sounds better?
> >
> > "nodomain+nobody" or "no+body"
> 
> Corinna, hi.
> 
> I know you have asked others to chime in, but IMO you should go ahead and
> change it to “no+body”.

Done.

> I also would ask others to chime in regarding this package and
> specifically if it is one they would like to see in Cygwin.
> 
> I am also unclear on what the next steps are regarding this package
> submission. Does the package need 5 votes in order to be accepted? Does it
> only need 1 GTG vote because FUSE packages already exist on most major
> Linux distros?

A GTG should be ok here.


Thanks,
Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [ITP] FUSE 2.8

[Adrien JUND]

Hi,

Here is Liryna from Dokan-dev community, our project Dokany have the
same purpose of Bill project.
Like WinFSP, it is able to mount FUSE filesystem on cygwin before WinFSP exist.

I would like to point out that naming WinFSP package "fuse" is not the
right way to integrate WinFSP in cygwin.

The package is not related to fuse developers or community.
It would make the user believe that the package is an official fuse
project and I am not sure that’s what Nikratio from libfuse would
like.
The package should be renamed winfsp-fuse for give ability of cygwin
users to choose which solution they would like to use. Like
dokan-fuse, cbfs-fuse and other projects that offer the same
service...
All these packages would install their own libfuse for link
compatibility that use their own dependency.
Fuse name should be kept for official port by libfuse or by a future
integration directly compatible with windows kernels.
The official fuse window integration is an official request made by
devs on WPDEV. This request is well placed on the top so it is
probably only a question of time before windows do it in the same time
as the Linux subsystem integration.
https://wpdev.uservoice.com/forums/266908-command-prompt-console-bash-on-ubuntu-on-windo/suggestions/13522845-add-fuse-filesystem-in-userspace-support-in-wsl

I also would like to point out that WinFSP has absolutely no feedback
of any kind by users and has not been tested on all windows versions.
I think Kernel drivers should at least have some feedback and known as
used in production before choosing to be distributed as cygwin
package.
Unstable kernel drivers can create severity damage in case of BSOD
like windows or user file corruption.

These analyses are probably severe but for the good of cygwin users,
integrate kernel driver dependence should be well thought before
making the step.

Thanks,
Liryna

2016-07-22 9:59 GMT+02:00 Corinna Vinschen <corinna-cygwin@cygwin.com>:
> On Jul 21 22:11, Bill Zissimopoulos wrote:
>> On 7/20/16, 1:52 AM, Corinna Vinschen wrote:
>>
>> >We just might still want to change the name to "no+body".
>> >
>> >What do others on this list think?  What sounds better?
>> >
>> > "nodomain+nobody" or "no+body"
>>
>> Corinna, hi.
>>
>> I know you have asked others to chime in, but IMO you should go ahead and
>> change it to “no+body”.
>
> Done.
>
>> I also would ask others to chime in regarding this package and
>> specifically if it is one they would like to see in Cygwin.
>>
>> I am also unclear on what the next steps are regarding this package
>> submission. Does the package need 5 votes in order to be accepted? Does it
>> only need 1 GTG vote because FUSE packages already exist on most major
>> Linux distros?
>
> A GTG should be ok here.
>
>
> Thanks,
> Corinna
>
> --
> Corinna Vinschen                  Please, send mails regarding Cygwin to
> Cygwin Maintainer                 cygwin AT cygwin DOT com
> Red Hat

Re: [ITP] FUSE 2.8

[Marco Atzeri]

On 22/07/2016 14:30, Adrien JUND wrote:
> Hi,
>
> Here is Liryna from Dokan-dev community, our project Dokany have the
> same purpose of Bill project.
> Like WinFSP, it is able to mount FUSE filesystem on cygwin before WinFSP exist.
>
> I would like to point out that naming WinFSP package "fuse" is not the
> right way to integrate WinFSP in cygwin.
>
> The package is not related to fuse developers or community.
> It would make the user believe that the package is an official fuse
> project and I am not sure that’s what Nikratio from libfuse would
> like.
> The package should be renamed winfsp-fuse for give ability of cygwin
> users to choose which solution they would like to use. Like
> dokan-fuse, cbfs-fuse and other projects that offer the same
> service...
> All these packages would install their own libfuse for link
> compatibility that use their own dependency.
> Fuse name should be kept for official port by libfuse or by a future
> integration directly compatible with windows kernels.

winfsp-fuse is a reasonable name.
dokan-fuse also (IMHO)

> The official fuse window integration is an official request made by
> devs on WPDEV. This request is well placed on the top so it is
> probably only a question of time before windows do it in the same time
> as the Linux subsystem integration.
> https://wpdev.uservoice.com/forums/266908-command-prompt-console-bash-on-ubuntu-on-windo/suggestions/13522845-add-fuse-filesystem-in-userspace-support-in-wsl

This seems just a wish for the time being.
Also our team leader asked for a fork or for more support in
the implementation of it but MS have never supported it.
:-(

> I also would like to point out that WinFSP has absolutely no feedback
> of any kind by users and has not been tested on all windows versions.
> I think Kernel drivers should at least have some feedback and known as
> used in production before choosing to be distributed as cygwin
> package.
> Unstable kernel drivers can create severity damage in case of BSOD
> like windows or user file corruption.
>
> These analyses are probably severe but for the good of cygwin users,
> integrate kernel driver dependence should be well thought before
> making the step.
>
> Thanks,
> Liryna

In general accepting a package is not endorsing its usage or quality.
We leave that to upstream responsibility, like it was for libusb.


Regards
Marco

Re: [ITP] FUSE 2.8

[Corinna Vinschen]

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

On Jul 22 14:53, Marco Atzeri wrote:
> On 22/07/2016 14:30, Adrien JUND wrote:
> > Hi,
> > 
> > Here is Liryna from Dokan-dev community, our project Dokany have the
> > same purpose of Bill project.
> > Like WinFSP, it is able to mount FUSE filesystem on cygwin before WinFSP exist.
> > 
> > I would like to point out that naming WinFSP package "fuse" is not the
> > right way to integrate WinFSP in cygwin.
> > 
> > The package is not related to fuse developers or community.
> > It would make the user believe that the package is an official fuse
> > project and I am not sure that’s what Nikratio from libfuse would
> > like.
> > The package should be renamed winfsp-fuse for give ability of cygwin
> > users to choose which solution they would like to use. Like
> > dokan-fuse, cbfs-fuse and other projects that offer the same
> > service...
> > All these packages would install their own libfuse for link
> > compatibility that use their own dependency.
> > Fuse name should be kept for official port by libfuse or by a future
> > integration directly compatible with windows kernels.
> 
> winfsp-fuse is a reasonable name.
> dokan-fuse also (IMHO)
> 
> > The official fuse window integration is an official request made by
> > devs on WPDEV. This request is well placed on the top so it is
> > probably only a question of time before windows do it in the same time
> > as the Linux subsystem integration.
> > https://wpdev.uservoice.com/forums/266908-command-prompt-console-bash-on-ubuntu-on-windo/suggestions/13522845-add-fuse-filesystem-in-userspace-support-in-wsl
> 
> This seems just a wish for the time being.
> Also our team leader asked for a fork or for more support in
> the implementation of it but MS have never supported it.
> :-(

WSL is it's own subsystem, while Cygwin runs in the Windows subsystem.
So even if MSFT implements it, we probably can't use it.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [ITP] FUSE 2.8

[Bill Zissimopoulos]

>winfsp-fuse is a reasonable name.
>dokan-fuse also (IMHO)

In the interest of moving things forward, I am happy to rename the
package. Is it possible for a package with a name winfsp-fuse to satisfy a
“fuse” dependency?

Bill

Re: [ITP] FUSE 2.8

[Marco Atzeri]

On 22/07/2016 19:58, Bill Zissimopoulos wrote:
>> winfsp-fuse is a reasonable name.
>> dokan-fuse also (IMHO)
>
> In the interest of moving things forward, I am happy to rename the
> package. Is it possible for a package with a name winfsp-fuse to satisfy a
> “fuse” dependency?
>
> Bill
>

It is not clear to me what you mean.

If some package depends on winfsp-fuse, the dependency will be winfsp-fuse.

winfsp-fuse will require the external package winfsp.

Regards
Marco

Re: [ITP] FUSE 2.8

[Bill Zissimopoulos]

On 7/22/16, 12:57 PM, Marco Atzeri wrote:


>On 22/07/2016 19:58, Bill Zissimopoulos wrote:
>>> winfsp-fuse is a reasonable name.
>>> dokan-fuse also (IMHO)
>>
>> In the interest of moving things forward, I am happy to rename the
>> package. Is it possible for a package with a name winfsp-fuse to
>>satisfy a
>> “fuse” dependency?
>
>It is not clear to me what you mean.
>
>If some package depends on winfsp-fuse, the dependency will be
>winfsp-fuse.
>
>winfsp-fuse will require the external package winfsp.

My apologies for not making it clearer. What I meant to say is this:

Suppose I have a package XYZ that requires FUSE. Is it possible that the
“FUSE” dependency can be satisfied by either winfsp-fuse or dokan-fuse?

If that is not possible it looks like we would have to have winfsp-sshfs
or dokan-sshfs, etc. which IMO is less desirable.

Bill

Re: [ITP] FUSE 2.8

[Marco Atzeri]

On 23/07/2016 02:31, Bill Zissimopoulos wrote:
> On 7/22/16, 12:57 PM, Marco Atzeri wrote:
>
>
>> On 22/07/2016 19:58, Bill Zissimopoulos wrote:
>>>> winfsp-fuse is a reasonable name.
>>>> dokan-fuse also (IMHO)
>>>
>>> In the interest of moving things forward, I am happy to rename the
>>> package. Is it possible for a package with a name winfsp-fuse to
>>> satisfy a
>>> “fuse” dependency?
>>
>> It is not clear to me what you mean.
>>
>> If some package depends on winfsp-fuse, the dependency will be
>> winfsp-fuse.
>>
>> winfsp-fuse will require the external package winfsp.
>
> My apologies for not making it clearer. What I meant to say is this:
>
> Suppose I have a package XYZ that requires FUSE. Is it possible that the
> “FUSE” dependency can be satisfied by either winfsp-fuse or dokan-fuse?
>
> If that is not possible it looks like we would have to have winfsp-sshfs
> or dokan-sshfs, etc. which IMO is less desirable.
>
> Bill

It depends on the type of dependency

- The hard coded dependency is based on dll's

example : octave dll requires the readline dll provided by
the package libreadline7

  $ cygcheck /usr/bin/cygoctave-3.dll |grep readline
   E:\cygwin64\bin\cygreadline7.dll

  $ cygcheck -f $(cygpath -u  'E:\cygwin64\bin\cygreadline7.dll')
libreadline7-6.3.8-1

In this case the dependency is hard coded in the octave binary itself.
We don't have a way (yet) to provide the same dll from two different
packages. In theory it can be done with pre/prost install scripts
that copy and remove dll's in "/usr/bin" but it will be tricky.
We can not use links with dll's on cygwin for windows loader constrain.

- The dependency is based on command

ls -l /usr/bin/automake
lrwxrwxrwx 1 marco Administrators 34 Aug  3  2013 /usr/bin/automake -> 
/usr/share/autotools/am-wrapper.sh

64 $ cygcheck -f /usr/share/autotools/am-wrapper.sh
automake-9-1

$ cygcheck -cd |grep automake
automake                                9-1
automake1.10                            1.10.3-2
automake1.11                            1.11.6-2
automake1.12                            1.12.6-2
automake1.13                            1.13.4-1
automake1.14                            1.14.1-2
automake1.15                            1.15-1
automake1.4                             1.4p6-11
automake1.5                             1.5-11
automake1.6                             1.6.3-12
automake1.7                             1.7.9-11
automake1.8                             1.8.5-11
automake1.9                             1.9.6-11

automake is a wrapper package that can be defined
to match the needed version and pull all the versions

$ automake --version
automake (GNU automake) 1.14.1

$ cygcheck-dep -r automake

  automake: requires ( automake1.10 automake1.11 automake1.12 
automake1.13 automake1.14 automake1.15 automake1.4 automake1.5 
automake1.6 automake1.7 automake1.8 automake1.9 bash gawk )

Alternatives can also be used to manage command dependency

$ alternatives --display unison
unison - status is auto.
  link currently points to /usr/bin/unison-2.48
/usr/bin/unison-2.48 - priority 2048
Current `best' version is /usr/bin/unison-2.48.

specially when you need only one variant installed,
but several are potentiall available:

$ cygcheck -cd |grep unison
unison2.48                              2.48.3-2

$ cygcheck -p "bin/unison-"
Found 7 matches for bin/unison-
unison2.27-2.27.157-4 - unison2.27: Synchronize ...
unison2.32-2.32.52-4 - unison2.32: Synchronize ...
unison2.40-2.40.102-1 - unison2.40: Synchronize ..
unison2.45-2.45.28-1 - unison2.45: Synchronize ..
unison2.48-2.48.3-1 - unison2.48: Synchronize ..
unison2.48-2.48.3-2 - unison2.48: Synchronize ..
unison2.49-2.49.543-1 - unison2.49: Synchronize ..

Regards
Marco

PS: today there is only one case of packages providing same name dll's
and the solution is sub-optimal and working only as
- there is a preferred order
   openblas cygblas-0.dll is preferred versus lapack one.
- the maintainer is the same: me
More packages with the same dll collision will require to work on
pre/prost install scripts general solution.

Re: [ITP] FUSE 2.8

[Bill Zissimopoulos]

On 7/22/16, 11:01 PM, Marco Atzeri wrote:

>On 23/07/2016 02:31, Bill Zissimopoulos wrote:
>>Suppose I have a package XYZ that requires FUSE. Is it possible that the
>> “FUSE” dependency can be satisfied by either winfsp-fuse or dokan-fuse?
>>
>> If that is not possible it looks like we would have to have winfsp-sshfs
>> or dokan-sshfs, etc. which IMO is less desirable.

Marco, this is very useful information. Thank you. Allow me to take a
couple of days to digest it before I come back with a more detailed answer.

Bill

Re: [ITP] FUSE 2.8

[Bill Zissimopoulos]

On 7/22/16, 12:59 AM, Corinna Vinschen wrote:


>On Jul 21 22:11, Bill Zissimopoulos wrote:
>> On 7/20/16, 1:52 AM, Corinna Vinschen wrote:
>> 
>> >We just might still want to change the name to "no+body".
>> >
>> >What do others on this list think?  What sounds better?
>> >
>> > "nodomain+nobody" or "no+body"
>> 
>> Corinna, hi.
>> 
>> I know you have asked others to chime in, but IMO you should go ahead
>>and
>> change it to “no+body”.
>
>Done.

Excellent. Let me know if you wish for me to test the change.

>> I also would ask others to chime in regarding this package and
>> specifically if it is one they would like to see in Cygwin.
>> 
>> I am also unclear on what the next steps are regarding this package
>> submission. Does the package need 5 votes in order to be accepted? Does
>>it
>> only need 1 GTG vote because FUSE packages already exist on most major
>> Linux distros?
>
>A GTG should be ok here.

Thank you. Much appreciated. Any takers?

Bill

Re: [ITP] FUSE 2.8

[Adrien JUND]

Hi,

Here is Liryna from Dokan-dev community, our project Dokany have the
same purpose of Bill project.
Like WinFSP, it is able to mount FUSE filesystem on cygwin before WinFSP exist.

I would like to point out that naming WinFSP package "fuse" is not the
good way to integrate WinFSP in cygwin.

The package is not related to fuse developers or community.
It would make the user believe that the package is an official fuse
project and I am not sure that’s what Nikratio from libfuse would
like.
The package should be renamed winfsp-fuse for give ability of cygwin
users to choose which solution they would like to use. Like
dokan-fuse, cbfs-fuse and other projects that offer the same
service...
All these packages would install their own libfuse for link
compatibility that use their own dependency.
Fuse name should be kept for official port by libfuse or by a future
integration directly compatible with windows kernels.
The official fuse window integration is an official request made by
devs on WPDEV. This request is well placed on the top so it is
probably only a question of time before windows do it in the same time
as the Linux subsystem integration.
https://wpdev.uservoice.com/forums/266908-command-prompt-console-bash-on-ubuntu-on-windo/suggestions/13522845-add-fuse-filesystem-in-userspace-support-in-wsl

I also would like to point out that WinFSP has absolutely no feedback
of any kind by users and has not been tested on all windows versions.
I think Kernel drivers should at least have some feedback and known as
used in production before choosing to be distributed as cygwin
package.
Unstable kernel drivers can create severity damage in case of BSOD
like windows or user files corruption.

These analyses are probably severe but for the good of cygwin users,
integrate kernel driver dependence should be well thought before
making the step.

Thanks,
Liryna,

2016-07-22 9:59 GMT+02:00 Corinna Vinschen <corinna-cygwin@cygwin.com>:
>
> On Jul 21 22:11, Bill Zissimopoulos wrote:
> > On 7/20/16, 1:52 AM, Corinna Vinschen wrote:
> >
> > >We just might still want to change the name to "no+body".
> > >
> > >What do others on this list think?  What sounds better?
> > >
> > > "nodomain+nobody" or "no+body"
> >
> > Corinna, hi.
> >
> > I know you have asked others to chime in, but IMO you should go ahead and
> > change it to “no+body”.
>
> Done.
>
> > I also would ask others to chime in regarding this package and
> > specifically if it is one they would like to see in Cygwin.
> >
> > I am also unclear on what the next steps are regarding this package
> > submission. Does the package need 5 votes in order to be accepted? Does it
> > only need 1 GTG vote because FUSE packages already exist on most major
> > Linux distros?
>
> A GTG should be ok here.
>
>
> Thanks,
> Corinna
>
> --
> Corinna Vinschen                  Please, send mails regarding Cygwin to
> Cygwin Maintainer                 cygwin AT cygwin DOT com
> Red Hat

Re: [ITP] FUSE 2.8

[Bill Zissimopoulos]

On 7/22/16, 4:59 AM, Adrien JUND wrote:


>The package should be renamed winfsp-fuse for give ability of cygwin
>users to choose which solution they would like to use. Like
>dokan-fuse, cbfs-fuse and other projects that offer the same
>service...

I am not opposed to renaming the package if that’s what the Cygwin
community wants.

However I note that this may create the following problem. Packages that
depend on FUSE will need to have that dependency satisfied by a number of
different *-fuse packages. Perhaps the dependency system in Cygwin is
flexible enough to support this (I don’t know).

For example I am planning to follow up this submission with SSHFS and
FUSEPY submissions. I would like to make these packages depend on a FUSE
package, so that we do not end up with a winfsp-sshfs package, a
dokan-sshfs package, etc. Even more importantly I would like SSHFS and
FUSEPY to build/run out of the box without having to add special logic for
winfsp-fuse vs dokan-fuse, etc.


>The official fuse window integration is an official request made by
>devs on WPDEV. This request is well placed on the top so it is
>probably only a question of time before windows do it in the same time
>as the Linux subsystem integration.
>https://wpdev.uservoice.com/forums/266908-command-prompt-console-bash-on-u
>buntu-on-windo/suggestions/13522845-add-fuse-filesystem-in-userspace-suppo
>rt-in-wsl

I am sorry, but having worked for Microsoft this is definitely wishful
thinking. If anything Microsoft would likely do it themselves. Heck I
might just rejoin them and do it for them ;)

>I also would like to point out that WinFSP has absolutely no feedback
>of any kind by users and has not been tested on all windows versions.
>I think Kernel drivers should at least have some feedback and known as
>used in production before choosing to be distributed as cygwin
>package.
>Unstable kernel drivers can create severity damage in case of BSOD
>like windows or user files corruption.
>
>These analyses are probably severe but for the good of cygwin users,
>integrate kernel driver dependence should be well thought before
>making the step.

Rubbish!

I am sorry that you are so upset Liryna that I decided to create my own
project instead of continuing to contribute to Dokany. But to go around
and spread unsubstantiated rumors is not acceptable.

You do not know how many people use WinFsp. To claim that there is no
feedback is simply false. There is no feedback that you see, but there is
quite some favorable feedback that I have seen including commercial
propositions. Furthermore being the number 1 trending project on GitHub
(for the C language) certainly shows some favorable feedback.

I would strongly argue that WinFsp is stabler and takes file system
semantic correctness far more seriously than Dokany. I note that you use
my own file system test suites to test your file systems and that Dokany
breaks with such basic things like memory mapped files and share access. I
could enumerate all of Dokany’s failings, but I will spare you the
embarrassment.

Bill

Re: [ITP] FUSE 2.8

[Adrien JUND]

Take a step back, Bill :)

Here I am only concerned about a non-official fuse project "fuse"
willing to use the fuse name and that would fool cygwin users.

Since I never tested your solution, I only reuse your own sentence
from dokan Google groups/reddit
but if you continue to say that I spread rumors, I will be happy to
show every of your own words.

Dokan is also always in trending projects for the current day/week
when a release is made on reddit.
You will learn the truth that there is a different in the number of
"Stars" and the number of people/bot who really use the project.
For information on your last release: curl -u "username"
https://api.github.com/repos/billziss-gh/winfsp/releases
=> winfsp-0.14.16197.msi - "download_count": 24
>You do not know how many people use WinFsp ..
>Furthermore being the number 1 trending project on GitHub (for the C language) certainly shows some favorable feedback.
You seem to also don't know how many people use it.

>I note that you use my own file system test suites to test your file systems
Yes, we use some of your file system test suites since you propose to
use it for testing Dokan at first, should we not ?
We also use tools that we created and others from Microsoft.
I don't understand your point here :(

>takes file system semantic correctness far more seriously than Dokany
Yes Dokan come from far, we changed a lot and we keep going on this way
Please be my guess, here is the result of 2 years of works:
https://github.com/dokan-dev/dokany/graphs/contributors
http://isitmaintained.com/project/dokan-dev/dokany

>could enumerate all of Dokany’s failings, but I will spare you the embarrassment.
There is no embarrassment Bill ! We already told you that we would be
please to have a feedback from you on google groupe.
Having issues and fixing it is the only goal here. It is even why we
revived the project ! Fixing and improving it! Be also my guess for
it.
As an example, you added test suits (keep the good work !), we use
them and we fixed issues if there were.

Dokan come from far since it was an old project and there is nobody
that can say we didn't do our best and that we didn't take care of ALL
issues.
It is also a project that showed his strange during the age !

Normally I wouldn't answer to such message as you did but I seens you
are using the same arguments on every conversation comparing
WinFSP/Dokan, I have feel that I need to make things clear.
If you wanna continue this conversation, please do not use this cygwin
thread and lets continue how winfsp-fuse and dokan-fuse can be added
to cygwin packages we a correct dependancy.

Liryna

2016-07-22 19:55 GMT+02:00 Bill Zissimopoulos <billziss@navimatics.com>:
> On 7/22/16, 4:59 AM, Adrien JUND wrote:
>
>
>>The package should be renamed winfsp-fuse for give ability of cygwin
>>users to choose which solution they would like to use. Like
>>dokan-fuse, cbfs-fuse and other projects that offer the same
>>service...
>
> I am not opposed to renaming the package if that’s what the Cygwin
> community wants.
>
> However I note that this may create the following problem. Packages that
> depend on FUSE will need to have that dependency satisfied by a number of
> different *-fuse packages. Perhaps the dependency system in Cygwin is
> flexible enough to support this (I don’t know).
>
> For example I am planning to follow up this submission with SSHFS and
> FUSEPY submissions. I would like to make these packages depend on a FUSE
> package, so that we do not end up with a winfsp-sshfs package, a
> dokan-sshfs package, etc. Even more importantly I would like SSHFS and
> FUSEPY to build/run out of the box without having to add special logic for
> winfsp-fuse vs dokan-fuse, etc.
>
>
>>The official fuse window integration is an official request made by
>>devs on WPDEV. This request is well placed on the top so it is
>>probably only a question of time before windows do it in the same time
>>as the Linux subsystem integration.
>>https://wpdev.uservoice.com/forums/266908-command-prompt-console-bash-on-u
>>buntu-on-windo/suggestions/13522845-add-fuse-filesystem-in-userspace-suppo
>>rt-in-wsl
>
> I am sorry, but having worked for Microsoft this is definitely wishful
> thinking. If anything Microsoft would likely do it themselves. Heck I
> might just rejoin them and do it for them ;)
>
>>I also would like to point out that WinFSP has absolutely no feedback
>>of any kind by users and has not been tested on all windows versions.
>>I think Kernel drivers should at least have some feedback and known as
>>used in production before choosing to be distributed as cygwin
>>package.
>>Unstable kernel drivers can create severity damage in case of BSOD
>>like windows or user files corruption.
>>
>>These analyses are probably severe but for the good of cygwin users,
>>integrate kernel driver dependence should be well thought before
>>making the step.
>
> Rubbish!
>
> I am sorry that you are so upset Liryna that I decided to create my own
> project instead of continuing to contribute to Dokany. But to go around
> and spread unsubstantiated rumors is not acceptable.
>
> You do not know how many people use WinFsp. To claim that there is no
> feedback is simply false. There is no feedback that you see, but there is
> quite some favorable feedback that I have seen including commercial
> propositions. Furthermore being the number 1 trending project on GitHub
> (for the C language) certainly shows some favorable feedback.
>
> I would strongly argue that WinFsp is stabler and takes file system
> semantic correctness far more seriously than Dokany. I note that you use
> my own file system test suites to test your file systems and that Dokany
> breaks with such basic things like memory mapped files and share access. I
> could enumerate all of Dokany’s failings, but I will spare you the
> embarrassment.
>
> Bill
>

Re: [ITP] FUSE 2.8

[Bill Zissimopoulos]

On 7/22/16, 12:56 PM, Adrien JUND wrote:


>For information on your last release: curl -u "username"
>https://api.github.com/repos/billziss-gh/winfsp/releases
>=> winfsp-0.14.16197.msi - "download_count": 24

This is beginning to feel a bit weird. You seem to be rather obsessed with
how many users my project has. Hint: GitHub is not the primary place where
I make binary releases.

>You seem to also don't know how many people use it.

:-D

Ok, I will make sure to contact you next time I need to read web server
stats.

Bill

Re: [ITP] FUSE 2.8

[Corinna Vinschen]

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

On Jul 23 00:23, Bill Zissimopoulos wrote:
> On 7/22/16, 12:56 PM, Adrien JUND wrote:
> 
> 
> >For information on your last release: curl -u "username"
> >https://api.github.com/repos/billziss-gh/winfsp/releases
> >=> winfsp-0.14.16197.msi - "download_count": 24
> 
> This is beginning to feel a bit weird. You seem to be rather obsessed with
> how many users my project has. Hint: GitHub is not the primary place where
> I make binary releases.
> 
> >You seem to also don't know how many people use it.
> 
> :-D
> 
> Ok, I will make sure to contact you next time I need to read web server
> stats.

Guys,

no idea what's up between you, but this discussion is gross.

Here's an idea:  You both slap yourself and start talking to each other.

For the Windows *and* Cygwin world it would be *much* preferrable if you
work together and create a single, unified FUSE concept, rather than
having two projects doing almost, but not entirely, the same thing,
Worse, given that FUSE only makes sense if user-space filesystems exist,
we now have two FUSE concepts with a disjunct set of user-space drivers.

Great :(

My interest in both of your projects has just dwindled considerably.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [ITP] FUSE 2.8

[Bill Zissimopoulos]

On 7/23/16, 3:40 AM, Corinna Vinschen wrote:

>
>no idea what's up between you, but this discussion is gross...
>
>My interest in both of your projects has just dwindled considerably.

Corinna, understood. I think this may have been the point.

I was planning to work for a solution for how to have multiple *-fuse
packages coexist based on Marco’s great answer. If you do not believe
there is any interest any more please let me know.

Bill

Re: [ITP] FUSE 2.8

[Corinna Vinschen]

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

On Jul 23 16:43, Bill Zissimopoulos wrote:
> On 7/23/16, 3:40 AM, Corinna Vinschen wrote:
> 
> >
> >no idea what's up between you, but this discussion is gross...
> >
> >My interest in both of your projects has just dwindled considerably.
> 
> Corinna, understood. I think this may have been the point.

So you quoted my knee-jerk reaction but missed to quote the *real* point
of my mail.  Fixed that for you:

> > Here's an idea:  You both slap yourself and start talking to each other.
> > 
> > For the Windows *and* Cygwin world it would be *much* preferrable if you
> > work together and create a single, unified FUSE concept, rather than
> > having two projects doing almost, but not entirely, the same thing,
> > Worse, given that FUSE only makes sense if user-space filesystems exist,
> > we now have two FUSE concepts with a disjunct set of user-space drivers.

> I was planning to work for a solution for how to have multiple *-fuse
> packages coexist based on Marco’s great answer.

Which is not the answer I'd expected since it completely ignores the
part about "talking to each other", "single FUSE concept" and
"collaboration".

> If you do not believe
> there is any interest any more please let me know.

I was talking about *my* interest.  Naturally I'm not speaking for the
entire group of maintainers.

I wouldn't block a package if there's no good reason like licensing
problems or a package completly ignoring collision with other, existing
packages.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [ITP] FUSE 2.8

[Bill Zissimopoulos]

On 7/23/16, 10:48 AM, Corinna Vinschen wrote:


>So you quoted my knee-jerk reaction but missed to quote the *real* point
>of my mail.  Fixed that for you:
>
>> > Here's an idea:  You both slap yourself and start talking to each
>>other.
>> > 
>> > For the Windows *and* Cygwin world it would be *much* preferrable if
>>you
>> > work together and create a single, unified FUSE concept, rather than
>> > having two projects doing almost, but not entirely, the same thing,
>> > Worse, given that FUSE only makes sense if user-space filesystems
>>exist,
>> > we now have two FUSE concepts with a disjunct set of user-space
>>drivers.
>
>> I was planning to work for a solution for how to have multiple *-fuse
>> packages coexist based on Marco’s great answer.
>
>Which is not the answer I'd expected since it completely ignores the
>part about "talking to each other", "single FUSE concept" and
>"collaboration".

Corinna, I apologize to you and the list for not being on my best
behavior. However…

I *have* contributed to Dokany. Despite the fact that my own project is
independent and not a Dokan fork (and has a completely different
design/architecture), a couple of days ago I suggested on their mailing
list that I would still work with them. The events of the last couple of
days changed my mind.

I work on my project(s) because I can and because I find that it is fun,
even when I am debugging for 2 days why the LazyWriter hangs in some
obscure kernel corner. If it gets too political it stops being fun. If I
am forced to work on something I would rather not, it stops being fun too.

I want to contribute to Cygwin, because I have been a user since the early
2000’s and because I cannot live on Windows without it. I thought I had
something to contribute after all this time. Unfortunately it looks like
the price of admission may be higher than I am willing to pay at this time.

Thank you and regards,

Bill

Re: [ITP] FUSE 2.8

[Corinna Vinschen]

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

On Jul 23 18:33, Bill Zissimopoulos wrote:
> On 7/23/16, 10:48 AM, Corinna Vinschen wrote:
> 
> 
> >So you quoted my knee-jerk reaction but missed to quote the *real* point
> >of my mail.  Fixed that for you:
> >
> >> > Here's an idea:  You both slap yourself and start talking to each
> >>other.
> >> > 
> >> > For the Windows *and* Cygwin world it would be *much* preferrable if
> >>you
> >> > work together and create a single, unified FUSE concept, rather than
> >> > having two projects doing almost, but not entirely, the same thing,
> >> > Worse, given that FUSE only makes sense if user-space filesystems
> >>exist,
> >> > we now have two FUSE concepts with a disjunct set of user-space
> >>drivers.
> >
> >> I was planning to work for a solution for how to have multiple *-fuse
> >> packages coexist based on Marco’s great answer.
> >
> >Which is not the answer I'd expected since it completely ignores the
> >part about "talking to each other", "single FUSE concept" and
> >"collaboration".
> 
> Corinna, I apologize to you and the list for not being on my best
> behavior. However…
> 
> I *have* contributed to Dokany. Despite the fact that my own project is
> independent and not a Dokan fork (and has a completely different

This is one detail I missed here.  If this has been mentioned earlier
I apologise for not noticing it.  I was under the implression WinFsp and
dokany are from the same source code base,

> design/architecture), a couple of days ago I suggested on their mailing
> list that I would still work with them. The events of the last couple of
> days changed my mind.
> 
> I work on my project(s) because I can and because I find that it is fun,
> even when I am debugging for 2 days why the LazyWriter hangs in some
> obscure kernel corner. If it gets too political it stops being fun. If I
> am forced to work on something I would rather not, it stops being fun too.
> 
> I want to contribute to Cygwin, because I have been a user since the early
> 2000’s and because I cannot live on Windows without it. I thought I had
> something to contribute after all this time. Unfortunately it looks like
> the price of admission may be higher than I am willing to pay at this time.

As I said, I'm not going to refuse your package.  I was just pissed
about this discussion in conjunction with  my (now) obvious
misunderstanding that we're talking about two forks of the same code.

Please go ahead as planned,
Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [ITP] FUSE 2.8

[Bill Zissimopoulos]

>As I said, I'm not going to refuse your package.  I was just pissed
>about this discussion in conjunction with  my (now) obvious
>misunderstanding that we're talking about two forks of the same code.
>
>Please go ahead as planned,

Thanks. As I see it there are the following options:

- Accept/reject the current FUSE package as it has been submitted or with
requested corrections, fixes, etc. However the package has received no
plus/minus votes at this time.

- Rename the package to winfsp-fuse, but have it somehow “satisfy”
packages that require “fuse” (e.g. SSHFS, FUSEPY). This would allow
multiple *-fuse packages to exist in the setup database and the user
chooses which one they want. My understanding based on Marco’s answer is
that this is not currently supported by Cygwin’s dependency system.

Bill

Re: [ITP] FUSE 2.8

[Mark Geisert]

Bill Zissimopoulos writes:
> - Rename the package to winfsp-fuse, but have it somehow “satisfy”
> packages that require “fuse” (e.g. SSHFS, FUSEPY). This would allow
> multiple *-fuse packages to exist in the setup database and the user
> chooses which one they want. My understanding based on Marco’s answer is
> that this is not currently supported by Cygwin’s dependency system.

You could define a package "fuse" with no contents and a dependency on 
package "winfsp-fuse".  Then later when/if another FUSE implementation 
becomes available, "somebody" could replace the "fuse" package with 
whatever is required to get alternatives support for the variants.

I'm wondering if "fuse-xxxx" is a better name template than "xxxx-fuse" in 
order to keep the variants near each other in setup.exe's displays.

..mark

Re: [ITP] FUSE 2.8

[Herbert Stocker]

Hi all,

On 7/26/2016 8:27 AM, Mark Geisert wrote:
> You could define a package "fuse" with no contents and a dependency on
> package "winfsp-fuse".  Then later when/if another FUSE implementation
> becomes available, "somebody" could replace the "fuse" package with
> whatever is required to get alternatives support for the variants.

Does setup.exe already have a provision in the GUI to ask the user
which one they want to chose if two or more packages are able to
provide the (empty) fuse package?

> I'm wondering if "fuse-xxxx" is a better name template than "xxxx-fuse" in
> order to keep the variants near each other in setup.exe's displays.

good point.


Herbert Stocker

Re: [ITP] FUSE 2.8

[Adrien JUND]

>You could define a package "fuse" with no contents and a dependency on
>package "winfsp-fuse".  Then later when/if another FUSE implementation
>becomes available, "somebody" could replace the "fuse" package with
>whatever is required to get alternatives support for the variants.
I have not officially open request now but right after we found a
solution to handle fuse wrapper packages,
I will apply for dokan as well as winfsp.

Also, I think that packages binary dependent to a fuse wrapper would not work
if it is another wrapper that is installed.
So shall we not just let the package dependent to fuse, explicit the
wrapper that he will use ?

2016-07-26 10:45 GMT+02:00 Herbert Stocker <hersto@gmx.de>:
> Hi all,
>
> On 7/26/2016 8:27 AM, Mark Geisert wrote:
>>
>> You could define a package "fuse" with no contents and a dependency on
>> package "winfsp-fuse".  Then later when/if another FUSE implementation
>> becomes available, "somebody" could replace the "fuse" package with
>> whatever is required to get alternatives support for the variants.
>
>
> Does setup.exe already have a provision in the GUI to ask the user
> which one they want to chose if two or more packages are able to
> provide the (empty) fuse package?
>
>> I'm wondering if "fuse-xxxx" is a better name template than "xxxx-fuse" in
>> order to keep the variants near each other in setup.exe's displays.
>
>
> good point.
>
>
> Herbert Stocker

Re: [ITP] FUSE 2.8

[Mark Geisert]

Adrien JUND writes:
> >You could define a package "fuse" with no contents and a dependency 
on
> >package "winfsp-fuse".  Then later when/if another FUSE 
implementation
> >becomes available, "somebody" could replace the "fuse" package with
> >whatever is required to get alternatives support for the variants.

> I have not officially open request now but right after we found a
> solution to handle fuse wrapper packages,
> I will apply for dokan as well as winfsp.
> 
> Also, I think that packages binary dependent to a fuse wrapper would 
not work
> if it is another wrapper that is installed.
> So shall we not just let the package dependent to fuse, explicit the
> wrapper that he will use ?

Erm, I'm belatedly comprehending it's two independent FUSE 
implementations and not two versions with some common history.  OK.  If 
there's a documented binary API at some level of the FUSE definition 
that both implementations provide then that's what the proposed "fuse" 
package could export.  Both implementations would then independently 
supply code that meets the API.  I'm not sure how much extra work this 
means for both projects.

If a common API-level interface is unworkable for whatever reason, then 
we'll just have to live with two independent fuse implementations.  
Tools like sshfs will have to be supplied by both projects and will only 
work with the correct underlying FUSE implementation.

Something alternatives-like would be nice for an end user to switch 
between implementations, but I don't know if that's workable.  Should it 
be possible to have both implementations installed at the same time?

..mark

--
captcha: homely

Re: [ITP] FUSE 2.8

[Bill Zissimopoulos]

On 7/26/16, 11:13 AM, Mark Geisert wrote:


>Erm, I'm belatedly comprehending it's two independent FUSE
>implementations and not two versions with some common history.  OK.  If
>there's a documented binary API at some level of the FUSE definition
>that both implementations provide then that's what the proposed "fuse"
>package could export.  Both implementations would then independently
>supply code that meets the API.  I'm not sure how much extra work this
>means for both projects.

Mark, please see my other response, where I (think that I) proposed
something similar.

Bill

Re: [ITP] FUSE 2.8

[Bill Zissimopoulos]

On 7/25/16, 11:27 PM, Mark Geisert wrote:

>Bill Zissimopoulos writes:
>> - Rename the package to winfsp-fuse, but have it somehow “satisfy”
>> packages that require “fuse” (e.g. SSHFS, FUSEPY). This would allow
>> multiple *-fuse packages to exist in the setup database and the user
>> chooses which one they want. My understanding based on Marco’s answer is
>> that this is not currently supported by Cygwin’s dependency system.
>
>You could define a package "fuse" with no contents and a dependency on
>package "winfsp-fuse".  Then later when/if another FUSE implementation
>becomes available, "somebody" could replace the "fuse" package with
>whatever is required to get alternatives support for the variants.

I will try this although it might take a bit longer than I had hoped.
Somehow I had vacation mixed with a family emergency and my free time
suddenly became nil.

>I'm wondering if "fuse-xxxx" is a better name template than "xxxx-fuse"
>in 
>order to keep the variants near each other in setup.exe's displays.

Somehow I find xxxx-fuse better sounding than fuse-xxxx, but your point
about keeping them together in setup.exe displays is a very good one. I
see no real problem with renaming to fuse-winfsp.

Bill

Re: [ITP] FUSE 2.8

[Bill Zissimopoulos]

On 7/25/16, 11:27 PM, Mark Geisert wrote:


>Bill Zissimopoulos writes:
>> - Rename the package to winfsp-fuse, but have it somehow “satisfy”
>> packages that require “fuse” (e.g. SSHFS, FUSEPY). This would allow
>> multiple *-fuse packages to exist in the setup database and the user
>> chooses which one they want. My understanding based on Marco’s answer is
>> that this is not currently supported by Cygwin’s dependency system.
>
>You could define a package "fuse" with no contents and a dependency on
>package "winfsp-fuse".  Then later when/if another FUSE implementation
>becomes available, "somebody" could replace the "fuse" package with
>whatever is required to get alternatives support for the variants.

BTW, here is another alternative that I have been mulling around.

I can take the current Cygwin package source, place it under a liberal
license like the BSD and create a separate project out of it. The intent
of the new project would be to support different FUSE solutions for
Windows using a *single* package. Currently it only supports WinFsp, but
it could be modified to support Dokany or other solutions.

There are many benefits to such an approach IMO:

- A single FUSE package and a single cygfuse.dll.
- Works out of the box with all supported Windows user mode file system
solutions.
- No changes in Cygwin’s dependency system or setup.exe required.
- No user confusion.

The current FUSE package is actually very simple. It looks in the registry
to see if/where WinFsp is installed and then loads the WinFsp DLL using
dlopen and the WinFsp-FUSE symbols using dlsym. Presumably the same
technique could work with Dokany or other solution.

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

To clarify I do not volunteer to maintain such a project. Only to
kickstart it by contributing the existing package code. I would hope that
another maintainer emerges, one who is both unaffiliated to the existing
projects (Dokany, WinFsp, etc.) to ensure fairness and one that has
Cygwin’s interests in mind.

Let me know.

Bill

Re: [ITP] FUSE 2.8

[Mark Geisert]

Bill Zissimopoulos writes:
> BTW, here is another alternative that I have been mulling around.
> 
[...]

Very interesting.  I'll need a little more time to investigate; github is 
throwing unicorns at the moment.

Could the Dokany folks consider whether this kind of wrapping might work 
for them too?  I'm guessing they'll have a different a list of symbols to 
be dlsym'd (unless there's a common API) and possibly a different method 
to determine whether their driver is installed.

If this turns out to be a workable solution, I am willing to be maintainer 
of the glue library Bill is offering.
Thanks,

..mark

--
captcha: durability

Re: [ITP] FUSE 2.8

[Bill Zissimopoulos]

On 7/26/16, 12:02 PM, Mark Geisert wrote:

>Bill Zissimopoulos writes:
>> BTW, here is another alternative that I have been mulling around.
>> 
>[...]
>
>Very interesting.  I'll need a little more time to investigate; github is
>throwing unicorns at the moment.

Yes, I noticed that. I think it is back up.

>If this turns out to be a workable solution, I am willing to be maintainer
>of the glue library Bill is offering.

Excellent! Please let me know.

Bill

Re: [ITP] FUSE 2.8

[Bill Zissimopoulos]

On 7/26/16, 12:02 PM, Mark Geisert wrote:


>If this turns out to be a workable solution, I am willing to be maintainer
>of the glue library Bill is offering.

I have created a new repository here:

    https://github.com/billziss-gh/cygfuse

It contains the following:

- fuse.cygport
- cygfuse.c
    - The implementation of cygfuse.dll; this is WinFsp specific at this
time.
- fuse.pc.in
    - Pkg-config file.
- inc/fuse
    - FUSE headers from the WinFsp project.

[NOTE:
The FUSE headers may give the future maintainer some trouble. They are
admittedly a convoluted way of doing things. At the time I wrote them I
wanted them to serve as public headers offering a FUSE API for native
*and* Cygwin apps. I also wanted to have the option of not needing to link
with a libfuse.a or cygfuse.dll, thence the heavy use of “static inline”.

I expect that a future maintainer would refactor those heavily or perhaps
ditch them altogether and switch to the libfuse headers.]

To build the FUSE package, try:

    $ make cygport
    $ cd fuse-2.8-4.x86_64/dist/fuse/
    $ tar -C/ -xaf fuse-2.8-4.tar.xz

To test that things work, clone my sshfs repo from:

    https://github.com/billziss-gh/sshfs

And issue the following commands:

    $ autoreconf -i
    $ ./configure
    $ make
    $ ./sshfs -o idmap=user user@host: Y:	# do this from a non-admin prompt
    ...
    $ pkill sshfs

I have not changed the license yet, but will do so if Mark (or someone
else) takes over the repo.

Bill

PS: I am going AWOL this Friday.

Re: [ITP] FUSE 2.8

[Mark Geisert]

Bill Zissimopoulos writes:
> To test that things work, clone my sshfs repo from:
> 
>     https://github.com/billziss-gh/sshfs
> 
> And issue the following commands:
> 
>     $ autoreconf -i
>     $ ./configure

On my test machine (Win7 64, Cygwin 64) I get the errors shown below.  
But first let me ask...

> PS: I am going AWOL this Friday.

If you don't mind my asking, do you mean for the day, for a couple 
weeks, for ever, ???
Thanks,

..mark

Here is the tail end of the ./configure output:
--------8<--------
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.exe
checking for suffix of executables... .exe
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking whether gcc understands -c and -o together... yes
checking for style of include used by make... GNU
checking dependency style of gcc... gcc3
checking for library containing dlsym... none required
checking OpenSSH version... 6.9 >= 4.4, disabling NODELAY workaround
checking for pkg-config... /usr/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
checking for SSHFS... no
configure: error: Package requirements (fuse >= 2.3 glib-2.0 gthread-
2.0) were not met:

No package 'fuse' found
No package 'glib-2.0' found
No package 'gthread-2.0' found

Consider adjusting the PKG_CONFIG_PATH environment variable if you
installed software in a non-standard prefix.

Alternatively, you may set the environment variables SSHFS_CFLAGS
and SSHFS_LIBS to avoid the need to call pkg-config.
See the pkg-config man page for more details.
-------->8--------

The following shows I have glib2 installed.  I can't find a gthread 
package for Cygwin.  I've compiled cygfuse; what cygport command will 
satisfy the package reference for configure (newbie question this)?

$ cygcheck -c | egrep 'fuse|glib|gthread'
libglib2.0_0       2.46.2-4      OK

Re: [ITP] FUSE 2.8

[Bill Zissimopoulos]

On 7/27/16, 2:03 AM, Mark Geisert wrote:


>Bill Zissimopoulos writes:
>> To test that things work, clone my sshfs repo from:
>> 
>>     https://github.com/billziss-gh/sshfs
>> 
>> And issue the following commands:
>> 
>>     $ autoreconf -i
>>     $ ./configure
>
>On my test machine (Win7 64, Cygwin 64) I get the errors shown below.
>But first let me ask...

Please be mindful if you intend to test that the current released binary
of WinFsp does not support Windows 7. This is because the last release
erroneously uses a Windows 8 only API (GetOverlappedResultEx).

>> PS: I am going AWOL this Friday.
>
>If you don't mind my asking, do you mean for the day, for a couple
>weeks, for ever, ???

:-D

Sorry! I am realizing now this could be taken in a darker way than I
intended. I just meant I am going on vacation and that I have to attend to
some family matters. It is likely I will not be able to participate in
discussions for a few weeks.


>Here is the tail end of the ./configure output:
>--------8<--------
>configure: error: Package requirements (fuse >= 2.3 glib-2.0 gthread-
>2.0) were not met:
>
>No package 'fuse' found
>No package 'glib-2.0' found
>No package 'gthread-2.0' found
>-------->8--------
>
>The following shows I have glib2 installed.  I can't find a gthread
>package for Cygwin.  I've compiled cygfuse; what cygport command will
>satisfy the package reference for configure (newbie question this)?
>
>$ cygcheck -c | egrep 'fuse|glib|gthread'
>libglib2.0_0       2.46.2-4      OK

You will need libglib2.0-devel. This includes gthread-2.0 as well.

The reason it cannot find the FUSE package is because the cygfuse package
has not been “installed”. Here is how I build and install it.

    # how to build
    $ cd cygfuse
    $ git clean -dfx
    $ make cygport

    # list tarball contents
    $ tar taf fuse-2.8-4.x86_64/dist/fuse/fuse-2.8-4.tar.xz

    # how to install
    $ tar -C/ -xaf fuse-2.8-4.x86_64/dist/fuse/fuse-2.8-4.tar.xz

    # how to uninstall
    $ tar taf fuse-2.8-4.x86_64/dist/fuse/fuse-2.8-4.tar.xz | sed
's@.*@/&@' | xargs rm

You can verify that the cygfuse package has been installed properly:

    $ ls -l /usr/bin/cygfuse*
    -rwxr-xr-x 1 billziss None 14336 Jul 27 10:32 /usr/bin/cygfuse-2.8.dll

    $ ls -l /usr/include/fuse/
    total 28
    -rw-r--r-- 1 billziss None 7052 Jul 27 10:32 fuse.h
    -rw-r--r-- 1 billziss None 3912 Jul 27 10:32 fuse_common.h
    -rw-r--r-- 1 billziss None 3557 Jul 27 10:32 fuse_opt.h
    -rw-r--r-- 1 billziss None 8455 Jul 27 10:32 winfsp_fuse.h


    $ ls -l /usr/lib/libfuse*
    -rw-r--r-- 1 billziss None 19626 Jul 27 10:32
/usr/lib/libfuse-2.8.dll.a
    lrwxrwxrwx 1 billziss None    17 Jul 27 10:32 /usr/lib/libfuse.dll.a
-> libfuse-2.8.dll.a

    $ ls -ls /usr/lib/pkgconfig/fuse.pc
    1 -rw-r--r-- 1 billziss None 190 Jul 27 10:32
/usr/lib/pkgconfig/fuse.pc



After this SSHFS configure should be able to find the fuse.pc pkg-config
file and complete the SSHFS configuration.

Bill

Re: [ITP] FUSE 2.8

[Mark Geisert]

Bill Zissimopoulos wrote:
> Please be mindful if you intend to test that the current released binary
> of WinFsp does not support Windows 7. This is because the last release
> erroneously uses a Windows 8 only API (GetOverlappedResultEx).

It's your call obviously but do you want to forgo Win 7 support when many of the 
kind of developers who might be interested in FUSE on Windows are delaying or 
not bothering to upgrade to Win 8.x or Win 10 for various reasons?

Is there an alternative to that particular API that would allow Win 7 support?

>>> PS: I am going AWOL this Friday.
>>
>> If you don't mind my asking, do you mean for the day, for a couple
>> weeks, for ever, ???
>
> :-D
>
> Sorry! I am realizing now this could be taken in a darker way than I
> intended. I just meant I am going on vacation and that I have to attend to
> some family matters. It is likely I will not be able to participate in
> discussions for a few weeks.

Appreciate knowing the time frame :).

Your detailed build instructions worked fine for me.  I'll be unable to test 
until I set up a Win 8.x or Win 10 VM at some point.  But so far so good.

Since this cygfuse glue DLL is a separate package from your FUSE implementation, 
I guess it'll need a separate ITP.  Will you do the initial package upload and 
then turn maintainership over to me, or would you prefer I own the package from 
the start?  Either way OK with me.  I guess whoever will be doing the initial 
upload should be the ITP submitter as well.
Thanks,

..mark

Re: [ITP] FUSE 2.8

[Bill Zissimopoulos]

On 7/28/16, Mark Geisert wrote:


>Bill Zissimopoulos wrote:
>> Please be mindful if you intend to test that the current released binary
>> of WinFsp does not support Windows 7. This is because the last release
>> erroneously uses a Windows 8 only API (GetOverlappedResultEx).
>
>It's your call obviously but do you want to forgo Win 7 support when many
>of the 
>kind of developers who might be interested in FUSE on Windows are
>delaying or 
>not bothering to upgrade to Win 8.x or Win 10 for various reasons?

I agree. Win7 support will return soon. I am trying to get this fixed
before I leave tomorrow, but I also have some real (as in paying) work to
do so no guarantees.

>Is there an alternative to that particular API that would allow Win 7
>support?

This particular problem has been fixed by a combination of
WaitForSingleObject and GetOverlappedResult (GetOverlappedResultEx is
really a wrapper around WaitForSingeObject). But I have also discovered
another issue that is less trivial.

>Your detailed build instructions worked fine for me.  I'll be unable to
>test 
>until I set up a Win 8.x or Win 10 VM at some point.  But so far so good.

I am going to really try to get that Win 7 supporting build out by the end
of Thursday (Pacific time).

>Since this cygfuse glue DLL is a separate package from your FUSE
>implementation,
>I guess it'll need a separate ITP.  Will you do the initial package
>upload and 
>then turn maintainership over to me, or would you prefer I own the
>package from 
>the start?  Either way OK with me.  I guess whoever will be doing the
>initial 
>upload should be the ITP submitter as well.

Actually my ITP submission is this cygfuse DLL. Based on what you write
above it looks like you are happy to become the maintainer(?). If yes, it
would perhaps make sense for you to resubmit the package.

Please let me know if you agree and I will place the package under the BSD
and transfer ownership to you on GitHub.

Bill

Re: [ITP] FUSE 2.8

[Mark Geisert]

Bill Zissimopoulos wrote:
> On 7/28/16, Mark Geisert wrote:
>> Bill Zissimopoulos wrote:
>>> Please be mindful if you intend to test that the current released binary
>>> of WinFsp does not support Windows 7. This is because the last release
>>> erroneously uses a Windows 8 only API (GetOverlappedResultEx).
>>
>> It's your call obviously but do you want to forgo Win 7 support when many
>> of the
>> kind of developers who might be interested in FUSE on Windows are
>> delaying or
>> not bothering to upgrade to Win 8.x or Win 10 for various reasons?
>
> I agree. Win7 support will return soon. I am trying to get this fixed
> before I leave tomorrow, but I also have some real (as in paying) work to
> do so no guarantees.
>
>> Is there an alternative to that particular API that would allow Win 7
>> support?
>
> This particular problem has been fixed by a combination of
> WaitForSingleObject and GetOverlappedResult (GetOverlappedResultEx is
> really a wrapper around WaitForSingeObject). But I have also discovered
> another issue that is less trivial.

Argh.

>> Your detailed build instructions worked fine for me.  I'll be unable to
>> test
>> until I set up a Win 8.x or Win 10 VM at some point.  But so far so good.
>
> I am going to really try to get that Win 7 supporting build out by the end
> of Thursday (Pacific time).

That's the timezone I'm in.  I'll see what's going on later tonight :) .

>> Since this cygfuse glue DLL is a separate package from your FUSE
>> implementation,
>> I guess it'll need a separate ITP.  Will you do the initial package
>> upload and
>> then turn maintainership over to me, or would you prefer I own the
>> package from
>> the start?  Either way OK with me.  I guess whoever will be doing the
>> initial
>> upload should be the ITP submitter as well.
>
> Actually my ITP submission is this cygfuse DLL. Based on what you write
> above it looks like you are happy to become the maintainer(?). If yes, it
> would perhaps make sense for you to resubmit the package.
>
> Please let me know if you agree and I will place the package under the BSD
> and transfer ownership to you on GitHub.

My mistake.  I thought your FUSE implementation had to be compiled for Cygwin, 
in order to make use of the cygfuse glue logic.  But instead you have a native 
Windows FUSE implementation?  Won't you have ABI (not API) problems connecting 
those two pieces, depending on how the FUSE guts are implemented?  Apologies if 
you've sorted that all out; don't want to hold you up talking about solved aspects.

I agree with how you want to adjust license and transfer ownership.  I don't 
have a presence on GitHub but I should be able to grab cygfuse anyway.
Thanks much,

..mark

Re: [ITP] FUSE 2.8

[Bill Zissimopoulos]

On 7/28/16, 10:29 AM, Mark Geisert wrote:


>>I am going to really try to get that Win 7 supporting build out by the
>>end
>> of Thursday (Pacific time).
>
>That's the timezone I'm in.  I'll see what's going on later tonight :) .

Ok, great. Then we should be able to do this today.

>My mistake.  I thought your FUSE implementation had to be compiled for
>Cygwin, 
>in order to make use of the cygfuse glue logic.  But instead you have a
>native 
>Windows FUSE implementation?  Won't you have ABI (not API) problems
>connecting 
>those two pieces, depending on how the FUSE guts are implemented?
>Apologies if 
>you've sorted that all out; don't want to hold you up talking about
>solved aspects.

Yes. I have a FUSE implementation that works for native and Cygwin
programs. The ABI was indeed a bit of an issue, hence my use of fsp_fuse_*
symbols vs fuse_* symbols.

Quick example: instead of offering a fuse_loop symbol, WinFsp offers an
fsp_fuse_loop symbol. Then fuse_new is coded as (for native):

    static inline int fuse_loop(struct fuse *f)
    {
        return fsp_fuse_loop(fsp_fuse_env(), f);
    }

Similar code is used in the cygfuse DLL (in fact the same fuse_loop
definition is used on native and Cygwin through macro (ab)use).

The fsp_fuse_env() captures the “environment” which includes things like
the local MSVCRT/Cygwin malloc, etc. I also make sure not to use long
anywhere (since its size is different on Win64 vs Cygwin64).

I have some more information on this scheme here:

http://www.secfs.net/winfsp/blog/files/sshfs-port-case-study-step-2.html

>I agree with how you want to adjust license and transfer ownership.  I
>don't
>have a presence on GitHub but I should be able to grab cygfuse anyway.

Excellent. I will change the project to BSD and will explicitly say that I
am assigning ownership to you in the README/LICENSE files.

Bill

Re: [ITP] FUSE 2.8

[Bill Zissimopoulos]

Mark:

>I agree with how you want to adjust license and transfer ownership.  I
>don't 
>have a presence on GitHub but I should be able to grab cygfuse anyway.

Thank you very much for agreeing to become the maintainer for [CYGFUSE].
Please consider this post as my public announcement that I am relicensing
the [CYGFUSE] files under the BSD 2-clause license and that I am assigning
maintainership to Mark.

The project has been updated with a README and a LICENSE file that state
the same. Source files have been updated to reflect the license change as
well.

Mark, if at some point you do get a github account, I will be happy to
transfer ownership of the project as well. In the mean time do you have
somewhere where you intend to host it?

Regards,
Bill Zissimopoulos

[CYGFUSE]: https://github.com/billziss-gh/cygfuse

Re: [ITP] FUSE 2.8

[Bill Zissimopoulos]

>Mark, if at some point you do get a github account, I will be happy to
>transfer ownership of the project as well.

To clarify, I meant: “I will be happy to transfer ownership of the github
repository as well”.

Bill

Re: [ITP] FUSE 2.8

[Mark Geisert]

Bill Zissimopoulos wrote:
> Mark:
>
>> I agree with how you want to adjust license and transfer ownership.  I
>> don't
>> have a presence on GitHub but I should be able to grab cygfuse anyway.
>
> Thank you very much for agreeing to become the maintainer for [CYGFUSE].
> Please consider this post as my public announcement that I am relicensing
> the [CYGFUSE] files under the BSD 2-clause license and that I am assigning
> maintainership to Mark.
>
> The project has been updated with a README and a LICENSE file that state
> the same. Source files have been updated to reflect the license change as
> well.
>
> Mark, if at some point you do get a github account, I will be happy to
> transfer ownership of the project as well. In the mean time do you have
> somewhere where you intend to host it?
>
> Regards,
> Bill Zissimopoulos
>
> [CYGFUSE]: https://github.com/billziss-gh/cygfuse

I'll likely host it from my private http/ftp server at maxrnd.com, at least 
initially.  The cygutils package was there for review so I know it would work. 
I've been looking at some of the public repositories over time but haven't moved 
to one, largely because I haven't really needed it.

OK on your changes above including the minor correction you made afterwards.
Cheers,

..mark

Re: [ITP] FUSE 2.8

[Corinna Vinschen]

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

On Jul 28 12:58, Mark Geisert wrote:
> Bill Zissimopoulos wrote:
> > Mark:
> > 
> > > I agree with how you want to adjust license and transfer ownership.  I
> > > don't
> > > have a presence on GitHub but I should be able to grab cygfuse anyway.
> > 
> > Thank you very much for agreeing to become the maintainer for [CYGFUSE].
> > Please consider this post as my public announcement that I am relicensing
> > the [CYGFUSE] files under the BSD 2-clause license and that I am assigning
> > maintainership to Mark.
> > 
> > The project has been updated with a README and a LICENSE file that state
> > the same. Source files have been updated to reflect the license change as
> > well.
> > 
> > Mark, if at some point you do get a github account, I will be happy to
> > transfer ownership of the project as well. In the mean time do you have
> > somewhere where you intend to host it?
> > 
> > Regards,
> > Bill Zissimopoulos
> > 
> > [CYGFUSE]: https://github.com/billziss-gh/cygfuse
> 
> I'll likely host it from my private http/ftp server at maxrnd.com, at least
> initially.  The cygutils package was there for review so I know it would
> work. I've been looking at some of the public repositories over time but
> haven't moved to one, largely because I haven't really needed it.
> 
> OK on your changes above including the minor correction you made afterwards.
> Cheers,

Again, we have the Cygwin org @ github, https://github.com/cygwin.
You can simple put your repo under this cover.

Alternatively you can also get your own repo under the cygwin-apps
cover at cygwin.com/sourceware.org:

https://sourceware.org/cygwin-apps/
https://sourceware.org/git/


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [ITP] FUSE 2.8

[Corinna Vinschen]

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

On Jul 28 19:13, Bill Zissimopoulos wrote:
> Mark:
> 
> >I agree with how you want to adjust license and transfer ownership.  I
> >don't 
> >have a presence on GitHub but I should be able to grab cygfuse anyway.
> 
> Thank you very much for agreeing to become the maintainer for [CYGFUSE].
> Please consider this post as my public announcement that I am relicensing
> the [CYGFUSE] files under the BSD 2-clause license and that I am assigning
> maintainership to Mark.
> 
> The project has been updated with a README and a LICENSE file that state
> the same. Source files have been updated to reflect the license change as
> well.
> 
> Mark, if at some point you do get a github account, I will be happy to
> transfer ownership of the project as well. In the mean time do you have
> somewhere where you intend to host it?

github Cygwin org?

https://github.com/cygwin

Every Cygwin-related project is welcome.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [ITP] FUSE 2.8

[Bill Zissimopoulos]

On 7/28/16, 1:04 PM, Corinna Vinschen wrote:


>On Jul 28 19:13, Bill Zissimopoulos wrote:
>> Mark:
>> 
>> >I agree with how you want to adjust license and transfer ownership.  I
>> >don't 
>> >have a presence on GitHub but I should be able to grab cygfuse anyway.
>> 
>> Thank you very much for agreeing to become the maintainer for [CYGFUSE].
>> Please consider this post as my public announcement that I am
>>relicensing
>> the [CYGFUSE] files under the BSD 2-clause license and that I am
>>assigning
>> maintainership to Mark.
>> 
>> The project has been updated with a README and a LICENSE file that state
>> the same. Source files have been updated to reflect the license change
>>as
>> well.
>> 
>> Mark, if at some point you do get a github account, I will be happy to
>> transfer ownership of the project as well. In the mean time do you have
>> somewhere where you intend to host it?
>
>github Cygwin org?
>
>https://github.com/cygwin
>
>Every Cygwin-related project is welcome.

If Mark agrees, I am happy to transfer ownership of the github repo to the
cygwin@github.

Bill

Re: [ITP] FUSE 2.8

[Mark Geisert]

Bill Zissimopoulos wrote:
> On 7/28/16, 1:04 PM, Corinna Vinschen wrote:
>
>
>> On Jul 28 19:13, Bill Zissimopoulos wrote:
>>> Mark:
>>>
>>>> I agree with how you want to adjust license and transfer ownership.  I
>>>> don't
>>>> have a presence on GitHub but I should be able to grab cygfuse anyway.
>>>
>>> Thank you very much for agreeing to become the maintainer for [CYGFUSE].
>>> Please consider this post as my public announcement that I am
>>> relicensing
>>> the [CYGFUSE] files under the BSD 2-clause license and that I am
>>> assigning
>>> maintainership to Mark.
>>>
>>> The project has been updated with a README and a LICENSE file that state
>>> the same. Source files have been updated to reflect the license change
>>> as
>>> well.
>>>
>>> Mark, if at some point you do get a github account, I will be happy to
>>> transfer ownership of the project as well. In the mean time do you have
>>> somewhere where you intend to host it?
>>
>> github Cygwin org?
>>
>> https://github.com/cygwin
>>
>> Every Cygwin-related project is welcome.
>
> If Mark agrees, I am happy to transfer ownership of the github repo to the
> cygwin@github.

Sounds like a fine idea!

..mark

Re: [ITP] FUSE 2.8

[Bill Zissimopoulos]

On 7/28/16, 5:04 PM, Mark Geisert wrote:


>Bill Zissimopoulos wrote:
>> On 7/28/16, 1:04 PM, Corinna Vinschen wrote:
>>
>>>github Cygwin org?
>>>
>>> https://github.com/cygwin
>>>
>>> Every Cygwin-related project is welcome.
>>
>> If Mark agrees, I am happy to transfer ownership of the github repo to
>>the
>> cygwin@github.
>
>Sounds like a fine idea!

Ok. I did the transfer (twice, because of some ambiguous GitHub messages).
Someone from cygwin’s side has to accept the repo within a day according
to GitHub.

Bill

Re: [ITP] FUSE 2.8

[Bill Zissimopoulos]

On 7/28/16, 5:17 PM, Bill Zissimopoulos wrote:


>On 7/28/16, 5:04 PM, Mark Geisert wrote:
>
>>Bill Zissimopoulos wrote:
>>> On 7/28/16, 1:04 PM, Corinna Vinschen wrote:
>>>
>>>>github Cygwin org?
>>>>
>>>> https://github.com/cygwin
>>>>
>>>> Every Cygwin-related project is welcome.
>>>
>>> If Mark agrees, I am happy to transfer ownership of the github repo to
>>>the
>>> cygwin@github.
>>
>>Sounds like a fine idea!
>
>Ok. I did the transfer (twice, because of some ambiguous GitHub messages).
>Someone from cygwin’s side has to accept the repo within a day according
>to GitHub.

Turns out I can transfer a repo to another user, but not to an
organization that I do not have admin rights for:

From github’s transfer repo instructions:
<<
Transfer this repository to another user or to an organization where you
have admin rights.

>>

Bill

Re: [ITP] FUSE 2.8

[Mark Geisert]

Bill Zissimopoulos wrote:
> On 7/28/16, 5:17 PM, Bill Zissimopoulos wrote:
>> Ok. I did the transfer (twice, because of some ambiguous GitHub messages).
>> Someone from cygwin’s side has to accept the repo within a day according
>> to GitHub.
>
> Turns out I can transfer a repo to another user, but not to an
> organization that I do not have admin rights for:
>
>  From github’s transfer repo instructions:
> <<
> Transfer this repository to another user or to an organization where you
> have admin rights.
>
>>>

FWIW I've signed up with GitHub with username mgeisert.  I think I need to be 
invited to join the cygwin@github org.  Then maybe I can transfer your repo to 
me?  Corrections welcome...

..mark

Re: [ITP] FUSE 2.8

[Corinna Vinschen]

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

On Jul 29 01:19, Mark Geisert wrote:
> Bill Zissimopoulos wrote:
> > On 7/28/16, 5:17 PM, Bill Zissimopoulos wrote:
> > > Ok. I did the transfer (twice, because of some ambiguous GitHub messages).
> > > Someone from cygwin’s side has to accept the repo within a day according
> > > to GitHub.
> > 
> > Turns out I can transfer a repo to another user, but not to an
> > organization that I do not have admin rights for:
> > 
> >  From github’s transfer repo instructions:
> > <<
> > Transfer this repository to another user or to an organization where you
> > have admin rights.
> > 
> > > > 
> 
> FWIW I've signed up with GitHub with username mgeisert.  I think I need to
> be invited to join the cygwin@github org.  Then maybe I can transfer your
> repo to me?  Corrections welcome...

I invited you with email mark AT maxrnd DOT com

There appears to be a user account called mgeisert, but it has no further
info attached, not even a name.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [ITP] FUSE 2.8

[Mark Geisert]

Corinna Vinschen wrote:
> On Jul 29 01:19, Mark Geisert wrote:
>> Bill Zissimopoulos wrote:
>>> On 7/28/16, 5:17 PM, Bill Zissimopoulos wrote:
>>>> Ok. I did the transfer (twice, because of some ambiguous GitHub messages).
>>>> Someone from cygwin’s side has to accept the repo within a day according
>>>> to GitHub.
>>>
>>> Turns out I can transfer a repo to another user, but not to an
>>> organization that I do not have admin rights for:
>>>
>>>   From github’s transfer repo instructions:
>>> <<
>>> Transfer this repository to another user or to an organization where you
>>> have admin rights.
>>>
>>>>>
>>
>> FWIW I've signed up with GitHub with username mgeisert.  I think I need to
>> be invited to join the cygwin@github org.  Then maybe I can transfer your
>> repo to me?  Corrections welcome...
>
> I invited you with email mark AT maxrnd DOT com
>
> There appears to be a user account called mgeisert, but it has no further
> info attached, not even a name.

Thanks Corinna, I've accepted the invite and filled in my profile a bit.  How 
would I/we accept the repo as Bill mentions above?  Then I guess a transfer 
needs to be done after that?

..mark

Re: [ITP] FUSE 2.8

[Corinna Vinschen]

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

On Jul 29 02:15, Mark Geisert wrote:
> Corinna Vinschen wrote:
> > On Jul 29 01:19, Mark Geisert wrote:
> > > Bill Zissimopoulos wrote:
> > > > On 7/28/16, 5:17 PM, Bill Zissimopoulos wrote:
> > > > > Ok. I did the transfer (twice, because of some ambiguous GitHub messages).
> > > > > Someone from cygwin’s side has to accept the repo within a day according
> > > > > to GitHub.
> > > > 
> > > > Turns out I can transfer a repo to another user, but not to an
> > > > organization that I do not have admin rights for:
> > > > 
> > > >   From github’s transfer repo instructions:
> > > > <<
> > > > Transfer this repository to another user or to an organization where you
> > > > have admin rights.
> > > > 
> > > > > > 
> > > 
> > > FWIW I've signed up with GitHub with username mgeisert.  I think I need to
> > > be invited to join the cygwin@github org.  Then maybe I can transfer your
> > > repo to me?  Corrections welcome...
> > 
> > I invited you with email mark AT maxrnd DOT com
> > 
> > There appears to be a user account called mgeisert, but it has no further
> > info attached, not even a name.
> 
> Thanks Corinna, I've accepted the invite and filled in my profile a bit.
> How would I/we accept the repo as Bill mentions above?  Then I guess a
> transfer needs to be done after that?

I really don't know, sorry.  I'm not actually using github a lot since
the cygwin repo is only mirrored to github.  I'd guess there's some
kind of documentation on github explaining stuff like that...?


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [ITP] FUSE 2.8

[Corinna Vinschen]

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

On Jul 29 11:48, Corinna Vinschen wrote:
> On Jul 29 02:15, Mark Geisert wrote:
> > Corinna Vinschen wrote:
> > > On Jul 29 01:19, Mark Geisert wrote:
> > > > Bill Zissimopoulos wrote:
> > > > > On 7/28/16, 5:17 PM, Bill Zissimopoulos wrote:
> > > > > > Ok. I did the transfer (twice, because of some ambiguous GitHub messages).
> > > > > > Someone from cygwin’s side has to accept the repo within a day according
> > > > > > to GitHub.
> > > > > 
> > > > > Turns out I can transfer a repo to another user, but not to an
> > > > > organization that I do not have admin rights for:
> > > > > 
> > > > >   From github’s transfer repo instructions:
> > > > > <<
> > > > > Transfer this repository to another user or to an organization where you
> > > > > have admin rights.
> > > > > 
> > > > > > > 
> > > > 
> > > > FWIW I've signed up with GitHub with username mgeisert.  I think I need to
> > > > be invited to join the cygwin@github org.  Then maybe I can transfer your
> > > > repo to me?  Corrections welcome...
> > > 
> > > I invited you with email mark AT maxrnd DOT com
> > > 
> > > There appears to be a user account called mgeisert, but it has no further
> > > info attached, not even a name.
> > 
> > Thanks Corinna, I've accepted the invite and filled in my profile a bit.
> > How would I/we accept the repo as Bill mentions above?  Then I guess a
> > transfer needs to be done after that?
> 
> I really don't know, sorry.  I'm not actually using github a lot since
> the cygwin repo is only mirrored to github.  I'd guess there's some
> kind of documentation on github explaining stuff like that...?

Mark, did you find out how to move the repo under the Cygwin org
in the meantime?  Is it the "Import repository" functionality by
any chance?


Thanks,
Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [ITP] FUSE 2.8

[Mark Geisert]

Corinna Vinschen wrote:
> On Jul 29 11:48, Corinna Vinschen wrote:
>> On Jul 29 02:15, Mark Geisert wrote:
>>> Corinna Vinschen wrote:
>>>> On Jul 29 01:19, Mark Geisert wrote:
>>>>> Bill Zissimopoulos wrote:
>>>>>> On 7/28/16, 5:17 PM, Bill Zissimopoulos wrote:
>>>>>>> Ok. I did the transfer (twice, because of some ambiguous GitHub messages).
>>>>>>> Someone from cygwin’s side has to accept the repo within a day according
>>>>>>> to GitHub.
>>>>>>
>>>>>> Turns out I can transfer a repo to another user, but not to an
>>>>>> organization that I do not have admin rights for:
>>>>>>
>>>>>>    From github’s transfer repo instructions:
>>>>>> <<
>>>>>> Transfer this repository to another user or to an organization where you
>>>>>> have admin rights.
>>>>>>
>>>>>>>>
>>>>>
>>>>> FWIW I've signed up with GitHub with username mgeisert.  I think I need to
>>>>> be invited to join the cygwin@github org.  Then maybe I can transfer your
>>>>> repo to me?  Corrections welcome...
>>>>
>>>> I invited you with email mark AT maxrnd DOT com
>>>>
>>>> There appears to be a user account called mgeisert, but it has no further
>>>> info attached, not even a name.
>>>
>>> Thanks Corinna, I've accepted the invite and filled in my profile a bit.
>>> How would I/we accept the repo as Bill mentions above?  Then I guess a
>>> transfer needs to be done after that?
>>
>> I really don't know, sorry.  I'm not actually using github a lot since
>> the cygwin repo is only mirrored to github.  I'd guess there's some
>> kind of documentation on github explaining stuff like that...?
>
> Mark, did you find out how to move the repo under the Cygwin org
> in the meantime?  Is it the "Import repository" functionality by
> any chance?

Hi Corinna,
Bill and I worked it out on a different thread of this conversation.  I 
currently have a public repo mgeisert/cygfuse on GitHub.  That seemed to be 
sufficient to me as maintainer.  Does it need to be moved under cygwin/ ?  If 
yes, it looks like "Import Repository" is a way to do it.

I was planning to make sure the package Bill supplied met all the requirements 
for a Cygwin package.  I figure it's real close but there was something I wasn't 
sure about and needed to research further, then real life intervened.  Something 
to do with where its cygport file was getting package source from.

..mark

Re: [ITP] FUSE 2.8

[Corinna Vinschen]

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

Hi Mark,

On Aug 17 01:26, Mark Geisert wrote:
> Corinna Vinschen wrote:
> > On Jul 29 11:48, Corinna Vinschen wrote:
> > > On Jul 29 02:15, Mark Geisert wrote:
> > > > Thanks Corinna, I've accepted the invite and filled in my profile a bit.
> > > > How would I/we accept the repo as Bill mentions above?  Then I guess a
> > > > transfer needs to be done after that?
> > > 
> > > I really don't know, sorry.  I'm not actually using github a lot since
> > > the cygwin repo is only mirrored to github.  I'd guess there's some
> > > kind of documentation on github explaining stuff like that...?
> > 
> > Mark, did you find out how to move the repo under the Cygwin org
> > in the meantime?  Is it the "Import repository" functionality by
> > any chance?
> 
> Hi Corinna,
> Bill and I worked it out on a different thread of this conversation.  I
> currently have a public repo mgeisert/cygfuse on GitHub.  That seemed to be
> sufficient to me as maintainer.  Does it need to be moved under cygwin/ ?
> If yes, it looks like "Import Repository" is a way to do it.

It doesn't *need* to be but it would be neat and helpful to have 
closley Cygwin-related projects in the Cygwin org.

> I was planning to make sure the package Bill supplied met all the
> requirements for a Cygwin package.  I figure it's real close but there was
> something I wasn't sure about and needed to research further, then real life
> intervened.  Something to do with where its cygport file was getting package
> source from.

Directly from git?  See, e.g., the cygwin package's cygport.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [ITP] FUSE 2.8

[Mark Geisert]

On Wed, 17 Aug 2016, Corinna Vinschen wrote:
>>> Mark, did you find out how to move the repo under the Cygwin org
>>> in the meantime?  Is it the "Import repository" functionality by
>>> any chance?
>>
>> Hi Corinna,
>> Bill and I worked it out on a different thread of this conversation.  I
>> currently have a public repo mgeisert/cygfuse on GitHub.  That seemed to be
>> sufficient to me as maintainer.  Does it need to be moved under cygwin/ ?
>> If yes, it looks like "Import Repository" is a way to do it.
>
> It doesn't *need* to be but it would be neat and helpful to have
> closley Cygwin-related projects in the Cygwin org.

I don't have any objection to that in principle.  It's hard for me to tell 
if this project qualifies that way, though.  Conceptually it's kind of 
like a VFS layer, but the core functionality is in Bill's separate 
Windows-native WinFSP dll.  The Cygwin end of things is just a bunch of 
wrappers around WinFSP calls all collected in a Cygwin dll.  (BTW, I don't 
see how transparency is supposed to work in a setup like this.)

>> I was planning to make sure the package Bill supplied met all the
>> requirements for a Cygwin package.  I figure it's real close but there was
>> something I wasn't sure about and needed to research further, then real life
>> intervened.  Something to do with where its cygport file was getting package
>> source from.
>
> Directly from git?  See, e.g., the cygwin package's cygport.

OK.  The cygfuse.cygport file is referring to Bill's separate GitHub space 
for source code.  Not sure it ought to do that.  Either my GitHub space 
(as I'm the Cygwin cygfuse maintainer) or Cygwin's GitHub space seems 
better.

I'm debugging some faulting test programs so this cygfuse code doesn't 
seem fully ready for prime time just yet.  I'm sure Bill had it working so 
it's likely to be some kind of local issue, so it's mine to solve.

..mark

Re: [ITP] FUSE 2.8

[Corinna Vinschen]

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

On Aug 22 02:43, Mark Geisert wrote:
> On Wed, 17 Aug 2016, Corinna Vinschen wrote:
> > > > Mark, did you find out how to move the repo under the Cygwin org
> > > > in the meantime?  Is it the "Import repository" functionality by
> > > > any chance?
> > > 
> > > Hi Corinna,
> > > Bill and I worked it out on a different thread of this conversation.  I
> > > currently have a public repo mgeisert/cygfuse on GitHub.  That seemed to be
> > > sufficient to me as maintainer.  Does it need to be moved under cygwin/ ?
> > > If yes, it looks like "Import Repository" is a way to do it.
> > 
> > It doesn't *need* to be but it would be neat and helpful to have
> > closley Cygwin-related projects in the Cygwin org.
> 
> I don't have any objection to that in principle.  It's hard for me to tell
> if this project qualifies that way, though.

No worries, it's your call.  We just provide the Cygwin org for all of
us to share.  It would be a pity if it goes mostly unused.

> Conceptually it's kind of like
> a VFS layer, but the core functionality is in Bill's separate Windows-native
> WinFSP dll.  The Cygwin end of things is just a bunch of wrappers around
> WinFSP calls all collected in a Cygwin dll.  (BTW, I don't see how
> transparency is supposed to work in a setup like this.)

I guess you'd need to discuss this with Bill.

> > > I was planning to make sure the package Bill supplied met all the
> > > requirements for a Cygwin package.  I figure it's real close but there was
> > > something I wasn't sure about and needed to research further, then real life
> > > intervened.  Something to do with where its cygport file was getting package
> > > source from.
> > 
> > Directly from git?  See, e.g., the cygwin package's cygport.
> 
> OK.  The cygfuse.cygport file is referring to Bill's separate GitHub space
> for source code.  Not sure it ought to do that.  Either my GitHub space (as
> I'm the Cygwin cygfuse maintainer) or Cygwin's GitHub space seems better.

In theory it doesn't matter, as long as the github space is open to
the public and the license is OSS compatible.

> I'm debugging some faulting test programs so this cygfuse code doesn't seem
> fully ready for prime time just yet.  I'm sure Bill had it working so it's
> likely to be some kind of local issue, so it's mine to solve.

Ok.


Thanks,
Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [ITP] FUSE 2.8

[Bill Zissimopoulos]

Mark, hi:

On 8/22/16, 12:43 PM, cygwin-apps-owner@cygwin.com on behalf of Mark
Geisert wrote:


>>>I was planning to make sure the package Bill supplied met all the
>>> requirements for a Cygwin package.  I figure it's real close but there
>>>was
>>> something I wasn't sure about and needed to research further, then
>>>real life
>>> intervened.  Something to do with where its cygport file was getting
>>>package
>>> source from.
>>
>> Directly from git?  See, e.g., the cygwin package's cygport.
>
>OK.  The cygfuse.cygport file is referring to Bill's separate GitHub
>space 
>for source code.  Not sure it ought to do that.  Either my GitHub space
>(as I'm the Cygwin cygfuse maintainer) or Cygwin's GitHub space seems
>better.
>
>I'm debugging some faulting test programs so this cygfuse code doesn't
>seem fully ready for prime time just yet.  I'm sure Bill had it working
>so 
>it's likely to be some kind of local issue, so it's mine to solve.

While still on vacation I now have reliable access to the Internet and am
able to follow up on any issues. Please let me know what the issue you are
seeing is and I will try to help.

Bill

Re: [ITP] FUSE 2.8

[Mark Geisert]

Bill Zissimopoulos wrote:
> Mark, hi:
>
> On 8/22/16, 12:43 PM, cygwin-apps-owner@cygwin.com on behalf of Mark
> Geisert wrote:
 >
>> I'm debugging some faulting test programs so this cygfuse code doesn't
>> seem fully ready for prime time just yet.  I'm sure Bill had it working
>> so
>> it's likely to be some kind of local issue, so it's mine to solve.
>
> While still on vacation I now have reliable access to the Internet and am
> able to follow up on any issues. Please let me know what the issue you are
> seeing is and I will try to help.

Sorry for the delay.  I've 'git clone'd the cygfuse repository and have been 
poking around, building and testing things.  'make cygfuse-test.exe' does build 
a cygfuse-test.exe but running it yields a core dump.  Exit status is 134.

I'm just running it without any args.  Is that abort a symptom of not having the 
WinFSP driver loaded, or something else?  Cygfuse works for both 32- and 64-bit 
Windows environments, right (assuming you're running the correct one)?

Separate from that, it's been a little work disentangling the meaning of various 
names used for this project.  Here's what I think the names mean:

FUSE - a protocol, which exists in different versions
WinFSP - a Windows-native DLL mapping FUSE 2.8 ops to/from Windows file ops
cygfuse - a Cygwin DLL allowing Cygwin SSHFS and FUSEPY to use WinFSP

If that's correct, I'd like to regularize the names of things in the proposed 
cygfuse package to accurately reflect their meaning.  E.g., change fuse.cygport 
to cygfuse.cygport, etc.  The doc inside some files might need updating.

I wasn't sure from Corinna's comments a while back (re hosting this package) 
whether she thought cygfuse should be part of Cygwin, as in placed in the Cygwin 
source tree, or just conveniently hosted on the Cygwin GitHub area.

That's where I'm at.  Thanks for reading.

..mark

Re: [ITP] FUSE 2.8

[Adrien JUND]

> Separate from that, it's been a little work disentangling the meaning of various names used for this project.  Here's what I think the names mean:
>
> FUSE - a protocol, which exists in different versions
> WinFSP - a Windows-native DLL mapping FUSE 2.8 ops to/from Windows file ops
> cygfuse - a Cygwin DLL allowing Cygwin SSHFS and FUSEPY to use WinFSP
>
> If that's correct, I'd like to regularize the names of things in the proposed cygfuse package to accurately reflect their meaning.  E.g., change fuse.cygport to cygfuse.cygport, etc.  The doc inside some files might need updating.

About cygfuse description, does the goal of cygfuse is not to wrappe
FUSE API for user land file systems like Dokan, WinFSP, CBFS, and
others ?

I have tried to see how to integrate Dokan in cygfuse and it is
currently hard linked to WinFSP and makes hard the integration for
others FS.
A neutral interface with common operations should be made to fix the situation.

Re: [ITP] FUSE 2.8

[Mark Geisert]

Adrien JUND wrote:
>> Separate from that, it's been a little work disentangling the meaning of various names used for this project.  Here's what I think the names mean:
>>
>> FUSE - a protocol, which exists in different versions
>> WinFSP - a Windows-native DLL mapping FUSE 2.8 ops to/from Windows file ops
>> cygfuse - a Cygwin DLL allowing Cygwin SSHFS and FUSEPY to use WinFSP
>>
>> If that's correct, I'd like to regularize the names of things in the proposed cygfuse package to accurately reflect their meaning.  E.g., change fuse.cygport to cygfuse.cygport, etc.  The doc inside some files might need updating.
>
> About cygfuse description, does the goal of cygfuse is not to wrappe
> FUSE API for user land file systems like Dokan, WinFSP, CBFS, and
> others ?
>
> I have tried to see how to integrate Dokan in cygfuse and it is
> currently hard linked to WinFSP and makes hard the integration for
> others FS.
> A neutral interface with common operations should be made to fix the situation.

I believe all interested parties have agreed we want to support multiple FUSE 
implementations.  cygfuse is intended to be the connector between a FUSE 
implementation and Cygwin versions of FUSE apps like SSHFS and FUSEPY.  The idea 
was to allow different FUSE implementations (e.g., WinFSP, Dokan, etc) under the 
hood without having to modify the Cygwin level apps SSHFS, FUSEPY, etc to match.

As currently implemented, cygfuse is hardwired to work with WinFSP.  That's only 
a consequence of cygfuse having been provided by WinFSP's author.  The plan is 
to extend cygfuse so that it can support multiple FUSE implementations of which 
one is selected at runtime.

Currently, if WinFSP is installed on the system (determined by the existence of 
a particular registry key) then cygfuse attaches to the WinFSP DLL.  This code 
needs to be extended to check whether Dokan is installed (determined by some 
mechanism TBD) and then attach to Dokan's DLL.  And so on for other future 
implementations.

I'm trying to get my understanding of the pieces and naming correct in order to 
modify the cygfuse code to be more generic and less tied to WinFSP.

..mark

Re: [ITP] FUSE 2.8

[Bill Zissimopoulos]

On 9/5/16, 1:16 PM, Mark Geisert wrote:


>Adrien JUND wrote:
>>> Separate from that, it's been a little work disentangling the meaning
>>>of various names used for this project.  Here's what I think the names
>>>mean:
>>>
>>> FUSE - a protocol, which exists in different versions
>>> WinFSP - a Windows-native DLL mapping FUSE 2.8 ops to/from Windows
>>>file ops
>>> cygfuse - a Cygwin DLL allowing Cygwin SSHFS and FUSEPY to use WinFSP
>>>
>>> If that's correct, I'd like to regularize the names of things in the
>>>proposed cygfuse package to accurately reflect their meaning.  E.g.,
>>>change fuse.cygport to cygfuse.cygport, etc.  The doc inside some files
>>>might need updating.
>>
>> About cygfuse description, does the goal of cygfuse is not to wrappe
>> FUSE API for user land file systems like Dokan, WinFSP, CBFS, and
>> others ?
>>
>> I have tried to see how to integrate Dokan in cygfuse and it is
>> currently hard linked to WinFSP and makes hard the integration for
>> others FS.
>> A neutral interface with common operations should be made to fix the
>>situation.
>
>I believe all interested parties have agreed we want to support multiple
>FUSE 
>implementations.  cygfuse is intended to be the connector between a FUSE
>implementation and Cygwin versions of FUSE apps like SSHFS and FUSEPY.
>The idea 
>was to allow different FUSE implementations (e.g., WinFSP, Dokan, etc)
>under the 
>hood without having to modify the Cygwin level apps SSHFS, FUSEPY, etc to
>match.
>
>As currently implemented, cygfuse is hardwired to work with WinFSP.
>That's only 
>a consequence of cygfuse having been provided by WinFSP's author.  The
>plan is 
>to extend cygfuse so that it can support multiple FUSE implementations of
>which 
>one is selected at runtime.
>
>Currently, if WinFSP is installed on the system (determined by the
>existence of 
>a particular registry key) then cygfuse attaches to the WinFSP DLL.  This
>code 
>needs to be extended to check whether Dokan is installed (determined by
>some 
>mechanism TBD) and then attach to Dokan's DLL.  And so on for other
>future 
>implementations.
>
>I'm trying to get my understanding of the pieces and naming correct in
>order to 
>modify the cygfuse code to be more generic and less tied to WinFSP.

Mark, thank you. I agree with everything you said.

Bill

Re: [ITP] FUSE 2.8

[Herbert Stocker]

Hi,

On 05.09.2016 22:16, Mark Geisert wrote:

> Currently, if WinFSP is installed on the system (determined by the
> existence of a particular registry key) then cygfuse attaches to the
> WinFSP DLL.  This code needs to be extended to check whether Dokan is
> installed (determined by some mechanism TBD) and then attach to Dokan's
> DLL.  And so on for other future implementations.

i think so, too. However, in the sense of neutrality and in case there
are both file systems installed, it should not give the one precedence
over the other. That means cygfuse should not just check for available
file systems and load the first found. There should be some user prece-
dence.
Maybe somebody wants to use WinFSP for Windows programs and Dokan for
Cygwin programs. There should be some user setting for the case both
are installed. Maybe some cygfuse-admin command could do the job.

Just a thought, not meant as high priority, because first we must get
more than one file system ready for use.

Herbert Stocker

Re: [ITP] FUSE 2.8

[Mark Geisert]

Herbert Stocker wrote:
> Maybe somebody wants to use WinFSP for Windows programs and Dokan for
> Cygwin programs. There should be some user setting for the case both
> are installed. Maybe some cygfuse-admin command could do the job.

This kind of flexibility would be nice.  We can of course only control the 
Cygwin environment though.  As a first cut I've implemented an environment 
variable CYGFUSE that can be set to either "WinFSP" or "Dokany" (any case 
allowed) to select which FUSE DLL to load at runtime.
Thanks,

..mark

Re: [ITP] FUSE 2.8

[Mark Geisert]

Hi Adrien,
I want to dig a little further into this...

Adrien JUND wrote:
> I have tried to see how to integrate Dokan in cygfuse and it is
> currently hard linked to WinFSP and makes hard the integration for
> others FS.
> A neutral interface with common operations should be made to fix the situation.

Cygfuse is intended to be the neutral interface.  I'll be making cosmetic 
changes to it to make it more clear what belongs to cygfuse and what belongs to 
FUSE implementation DLLs loaded by cygfuse.

Does the strategy of testing something in the environment for existence of 
Dokan, then if found, load a Dokan-specific DLL sound workable for you?  I want 
to be sure I'm not assuming too much about what FUSE implementations provide.

If you can be more specific about the gap between cygfuse as it is now and 
cygfuse being usable for you, please feel free.  You could also wait for a 
cosmetically updated cygfuse which I hope to have in "a few days" modulo real 
life interruptions.
Thanks much,

..mark

Re: [ITP] FUSE 2.8

[Bill Zissimopoulos]

On 9/5/16, 2:35 AM, Mark Geisert wrote:


>>While still on vacation I now have reliable access to the Internet and am
>> able to follow up on any issues. Please let me know what the issue you
>>are
>> seeing is and I will try to help.

Mark, I am now back from vacation and should be able to follow up more
reliably with this.

>Sorry for the delay.  I've 'git clone'd the cygfuse repository and have
>been
>poking around, building and testing things.  'make cygfuse-test.exe' does
>build 
>a cygfuse-test.exe but running it yields a core dump.  Exit status is 134.

Cygfuse-test was really a throw-away test program that I used during my
development. It simply checks that the cygfuse.dll can be loaded and the
fuse_version symbol is available. Here it is in its entirety:

    #include <fuse.h>
    int main()
    {
        return !(FUSE_VERSION == fuse_version());
    }


The most likely reason for the access violation is that the WinFsp DLL was
not installed. I note that cygfuse calls abort() (in
cygfuse.c:cygfuse_init_fail) if it cannot find the WinFsp DLL. This can be
changed to provide a more informative message of course.

>I'm just running it without any args.  Is that abort a symptom of not
>having the 
>WinFSP driver loaded, or something else?  Cygfuse works for both 32- and
>64-bit 
>Windows environments, right (assuming you're running the correct one)?

I have tested the WinFsp FSD/DLL in both 32- and 64-bit environments.
However cygfuse has only been tested in 64-bit environments so far.

>Separate from that, it's been a little work disentangling the meaning of
>various
>names used for this project.  Here's what I think the names mean:
>
>FUSE - a protocol, which exists in different versions
>WinFSP - a Windows-native DLL mapping FUSE 2.8 ops to/from Windows file
>ops
>cygfuse - a Cygwin DLL allowing Cygwin SSHFS and FUSEPY to use WinFSP
>
>If that's correct, I'd like to regularize the names of things in the
>proposed 
>cygfuse package to accurately reflect their meaning.  E.g., change
>fuse.cygport 
>to cygfuse.cygport, etc.  The doc inside some files might need updating.

I agree with your naming changes. Recall that I basically ripped the
cygfuse package out of WinFsp so the names will have to be revisited.

>I wasn't sure from Corinna's comments a while back (re hosting this
>package)
>whether she thought cygfuse should be part of Cygwin, as in placed in the
>Cygwin 
>source tree, or just conveniently hosted on the Cygwin GitHub area.

Corinna, should answer that. My understanding was that she would like to
see this package hosted in Cygwin’s GitHub area.

Bill

Re: [ITP] FUSE 2.8

[Corinna Vinschen]

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

On Sep  6 21:13, Bill Zissimopoulos wrote:
> On 9/5/16, 2:35 AM, Mark Geisert wrote:
> >to cygfuse.cygport, etc.  The doc inside some files might need updating.
> 
> I agree with your naming changes. Recall that I basically ripped the
> cygfuse package out of WinFsp so the names will have to be revisited.
> 
> >I wasn't sure from Corinna's comments a while back (re hosting this
> >package)
> >whether she thought cygfuse should be part of Cygwin, as in placed in the
> >Cygwin 
> >source tree, or just conveniently hosted on the Cygwin GitHub area.
> 
> Corinna, should answer that. My understanding was that she would like to
> see this package hosted in Cygwin’s GitHub area.

Y'all, don't get me wrong.  It would be *nice* and I'd love to see more
projects under this cover or under the cygwin-apps cover on cygwin.com/
sourceware.org, but it's not a hard requirement.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [ITP] FUSE 2.8

[Bill Zissimopoulos]

On 9/8/16, 5:01 AM, Corinna Vinschen wrote:

>On Sep  6 21:13, Bill Zissimopoulos wrote:
>> On 9/5/16, 2:35 AM, Mark Geisert wrote:
>>>I wasn't sure from Corinna's comments a while back (re hosting this
>> >package)
>> >whether she thought cygfuse should be part of Cygwin, as in placed in
>>the
>> >Cygwin 
>> >source tree, or just conveniently hosted on the Cygwin GitHub area.
>> 
>> Corinna, should answer that. My understanding was that she would like to
>> see this package hosted in Cygwin’s GitHub area.
>
>Y'all, don't get me wrong.  It would be *nice* and I'd love to see more
>projects under this cover or under the cygwin-apps cover on cygwin.com/
>sourceware.org, but it's not a hard requirement.

I favor this as well. But at this point it is Mark’s call.

Bill

Re: [ITP] FUSE 2.8

[Bill Zissimopoulos]

On 8/22/16, 12:43 PM, cygwin-apps-owner@cygwin.com on behalf of Mark
Geisert wrote:

>>>I was planning to make sure the package Bill supplied met all the
>>> requirements for a Cygwin package.  I figure it's real close but there
>>>was
>>> something I wasn't sure about and needed to research further, then
>>>real life
>>> intervened.  Something to do with where its cygport file was getting
>>>package
>>> source from.
>>
>> Directly from git?  See, e.g., the cygwin package's cygport.
>
>OK.  The cygfuse.cygport file is referring to Bill's separate GitHub
>space 
>for source code.  Not sure it ought to do that.  Either my GitHub space
>(as I'm the Cygwin cygfuse maintainer) or Cygwin's GitHub space seems
>better.

Regarding SRC_URI I needed to solve two problems: how to build the cygfuse
package given only the cygport source (which is what most other cygports
seem to do) and how to build the cygfuse package directly from its own
source tree for my own development purposes.

This is the reason for the CYGPORT_SRC_URI and CYGPORT_SRC_DIR vars. The
Makefile sets CYGPORT_SRC_URI/CYGPORT_SRC_DIR in such a way that
everything can be compiled locally. In normal usage CYGPORT_SRC_URI is not
set, so the source is picked up from github.

The reason that the default location is
"github.com/billziss-gh/cygfuse/..." is that at the time I was maintaining
the project. It should be changed to “github.com/mgeisert/cygfuse/..." now
of course.

Bill

Re: [ITP] FUSE 2.8

[Bill Zissimopoulos]

On 7/29/16, 1:19 AM, Mark Geisert wrote:


>FWIW I've signed up with GitHub with username mgeisert.  I think I need
>to be 
>invited to join the cygwin@github org.  Then maybe I can transfer your
>repo to 
>me?  Corrections welcome...

Hey, Mark. I just transferred the cygfuse repo under your name. Thanks.

Bill

Re: [ITP] FUSE 2.8

[Mark Geisert]

Bill Zissimopoulos wrote:
> On 7/29/16, 1:19 AM, Mark Geisert wrote:
>
>
>> FWIW I've signed up with GitHub with username mgeisert.  I think I need
>> to be
>> invited to join the cygwin@github org.  Then maybe I can transfer your
>> repo to
>> me?  Corrections welcome...
>
> Hey, Mark. I just transferred the cygfuse repo under your name. Thanks.

Great!  Thank you Bill for your contribution of Cygwin support for WinFSP.
Have a nice time AWOL :).

..mark

Re: [ITP] FUSE 2.8

[Bill Zissimopoulos]

Hi, Mark:

On 7/28/16, 10:29 AM, Mark Geisert wrote:


>>>>Please be mindful if you intend to test that the current released
>>>>binary
>>>> of WinFsp does not support Windows 7. This is because the last release
>>>> erroneously uses a Windows 8 only API (GetOverlappedResultEx).
>>>
>>> It's your call obviously but do you want to forgo Win 7 support when
>>>many
>>> of the
>>> kind of developers who might be interested in FUSE on Windows are
>>> delaying or
>>> not bothering to upgrade to Win 8.x or Win 10 for various reasons?
>>
>> I agree. Win7 support will return soon. I am trying to get this fixed
>> before I leave tomorrow, but I also have some real (as in paying) work
>>to
>> do so no guarantees.

Just wanted to let you know that I have made a new public release of
WinFsp, which should correctly work on all versions of Windows 7 and above.

You can download it from here:
	http://www.secfs.net/winfsp/download/

Thanks.

Bill

Re: [ITP] FUSE 2.8

[Mark Geisert]

Bill Zissimopoulos wrote:
> Hi, Mark:
>
> On 7/28/16, 10:29 AM, Mark Geisert wrote:
>
>
>>>>> Please be mindful if you intend to test that the current released
>>>>> binary
>>>>> of WinFsp does not support Windows 7. This is because the last release
>>>>> erroneously uses a Windows 8 only API (GetOverlappedResultEx).
>>>>
>>>> It's your call obviously but do you want to forgo Win 7 support when
>>>> many
>>>> of the
>>>> kind of developers who might be interested in FUSE on Windows are
>>>> delaying or
>>>> not bothering to upgrade to Win 8.x or Win 10 for various reasons?
>>>
>>> I agree. Win7 support will return soon. I am trying to get this fixed
>>> before I leave tomorrow, but I also have some real (as in paying) work
>>> to
>>> do so no guarantees.
>
> Just wanted to let you know that I have made a new public release of
> WinFsp, which should correctly work on all versions of Windows 7 and above.
>
> You can download it from here:
> 	http://www.secfs.net/winfsp/download/

Excellent!  Thanks for your patience and diligence on this.  I look forward to 
using WinFSP and taking over maintenance of the Cygwin end of it.
Cheers,

..mark

Re: [ITP] FUSE 2.8

[Adrien JUND]

Excellent idea Bill !
I am absolutely willing to do it !

Dokan install folder can also be retrieved from the registry so it is
a way to go with dlopen and dlsym mechanism.

Since I think all fuse wrapper in this fuse project should propose the
same FUSE VERSION,
I will need some time for updating it Dokan fuse that is currently 2.7
when WinFSP is 2.8.

Thank you Mark Geisert for willing to maintain it !

2016-07-26 20:38 GMT+02:00 Bill Zissimopoulos <billziss@navimatics.com>:
> On 7/25/16, 11:27 PM, Mark Geisert wrote:
>
>
>>Bill Zissimopoulos writes:
>>> - Rename the package to winfsp-fuse, but have it somehow “satisfy”
>>> packages that require “fuse” (e.g. SSHFS, FUSEPY). This would allow
>>> multiple *-fuse packages to exist in the setup database and the user
>>> chooses which one they want. My understanding based on Marco’s answer is
>>> that this is not currently supported by Cygwin’s dependency system.
>>
>>You could define a package "fuse" with no contents and a dependency on
>>package "winfsp-fuse".  Then later when/if another FUSE implementation
>>becomes available, "somebody" could replace the "fuse" package with
>>whatever is required to get alternatives support for the variants.
>
> BTW, here is another alternative that I have been mulling around.
>
> I can take the current Cygwin package source, place it under a liberal
> license like the BSD and create a separate project out of it. The intent
> of the new project would be to support different FUSE solutions for
> Windows using a *single* package. Currently it only supports WinFsp, but
> it could be modified to support Dokany or other solutions.
>
> There are many benefits to such an approach IMO:
>
> - A single FUSE package and a single cygfuse.dll.
> - Works out of the box with all supported Windows user mode file system
> solutions.
> - No changes in Cygwin’s dependency system or setup.exe required.
> - No user confusion.
>
> The current FUSE package is actually very simple. It looks in the registry
> to see if/where WinFsp is installed and then loads the WinFsp DLL using
> dlopen and the WinFsp-FUSE symbols using dlsym. Presumably the same
> technique could work with Dokany or other solution.
>
> https://github.com/billziss-gh/winfsp/tree/master/opt/cygfuse
>
> To clarify I do not volunteer to maintain such a project. Only to
> kickstart it by contributing the existing package code. I would hope that
> another maintainer emerges, one who is both unaffiliated to the existing
> projects (Dokany, WinFsp, etc.) to ensure fairness and one that has
> Cygwin’s interests in mind.
>
> Let me know.
>
> Bill
>

Re: [ITP] FUSE 2.8

[Bill Zissimopoulos]

On 7/26/16, 1:07 PM, Adrien JUND wrote:


>Excellent idea Bill !
>I am absolutely willing to do it !
>
>Dokan install folder can also be retrieved from the registry so it is
>a way to go with dlopen and dlsym mechanism.

Great. I am glad that this seems like it might work.

>Since I think all fuse wrapper in this fuse project should propose the
>same FUSE VERSION,
>I will need some time for updating it Dokan fuse that is currently 2.7
>when WinFSP is 2.8.

I agree.

Bill