Hi Jon, Achim,
Jon Turney wrote:
On 01/02/2022 06:20, ASSI wrote:
Mark Geisert writes:
I see that 'mtr' is another Cygwin package that makes use of a Windows
driver via libpcap. Maybe I can use mtr.cygport etc as a guide; I'm
unsure whether a Cygwin package should be including Windows
On 01/02/2022 06:20, ASSI wrote:
Mark Geisert writes:
I see that 'mtr' is another Cygwin package that makes use of a Windows
driver via libpcap. Maybe I can use mtr.cygport etc as a guide; I'm
unsure whether a Cygwin package should be including Windows drivers.
No they should not, although
One final reply to myself on this topic..
Thomas Wolff wrote:
What became of the winfsp-fuse project discussed in July 2016?
I'd like to be able to use ftpfs or sshfs in cygwin.
Integration of the project into Cygwin stalled around that time, or was it 2018?
[...]
I've now looked
Mark Geisert writes:
> I see that 'mtr' is another Cygwin package that makes use of a Windows
> driver via libpcap. Maybe I can use mtr.cygport etc as a guide; I'm
> unsure whether a Cygwin package should be including Windows drivers.
No they should not, although there is at least one other
Replying to myself...
Mark Geisert wrote:
Hi Thomas,
Thomas Wolff wrote:
What became of the winfsp-fuse project discussed in July 2016?
I'd like to be able to use ftpfs or sshfs in cygwin.
Integration of the project into Cygwin stalled around that time, or was it 2018?
[...]
I would love
Hi Thomas,
Thomas Wolff wrote:
What became of the winfsp-fuse project discussed in July 2016?
I'd like to be able to use ftpfs or sshfs in cygwin.
Integration of the project into Cygwin stalled around that time, or was it 2018?
ISTR there was an objection from the Dokany FUSE project about
What became of the winfsp-fuse project discussed in July 2016?
I'd like to be able to use ftpfs or sshfs in cygwin.
Thomas
>
>
>>I've changed Subject: to reflect what's being discussed now. When we
>>have a
>>consensus cygfuse I'll issue an ITP for it.
>>
>>I've now updated the cygfuse repository on GitHub so it is more neutral
>>about
>>FUSE implementations. It can be s
On 9/8/16, 1:03 AM, Mark Geisert wrote:
>I've changed Subject: to reflect what's being discussed now. When we
>have a
>consensus cygfuse I'll issue an ITP for it.
>
>I've now updated the cygfuse repository on GitHub so it is more neutral
>about
>FUSE implementations. It
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
>>
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
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
Mark Geisert wrote:
[... some stuff ...]
I've changed Subject: to reflect what's being discussed now. When we have a
consensus cygfuse I'll issue an ITP for it.
I've now updated the cygfuse repository on GitHub so it is more neutral about
FUSE implementations. It can be seen at https
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
.
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
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 protoco
er 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
>WinF
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
use 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 differ
On 8/22/16, 12:43 PM, cygwin-apps-ow...@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
Mark, hi:
On 8/22/16, 12:43 PM, cygwin-apps-ow...@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
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
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
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
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
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
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
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
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).
> > > > >
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.
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.
> >
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
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
y 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 upg
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
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
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
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
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
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
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
>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
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
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, d
).
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
x).
>
>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
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
n 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
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'
fuse.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
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.
>Sinc
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
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
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
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 an
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" packag
>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
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"
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 underst
ions:
- 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). T
elf 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 projec
or 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
*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
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
gt; 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
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
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
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 possibl
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
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
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 tha
>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
et 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
>> submi
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 packa
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 "
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
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
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,
C
order to be accepted? Does it
only need 1 GTG vote because FUSE packages already exist on most major
Linux distros?
Thanks.
Bill
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
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:
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 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.
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.
>>
>
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]
&g
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
> r
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. F
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
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 submitte
89 matches
Mail list logo
