fuse

fuse

[Thomas Wolff]

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

Re: fuse

[Mark Geisert]

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 whether WinFSP FUSE 
should be the basis for Cygwin's implementation.  I tried to mollify that by 
implementing a poor-man's plugin feature that would allow a user to select which 
underlying FUSE layer to use.  I believe I was waiting for confirmation from 
Dokany that they could work with that plugin architecture.

I think it was my ITP for libfuse that prompted the discussion with Dokany.  In 
any case the ITP was never acted on and the project has since languished.  WinFSP 
itself has been improved over time; I don't know if the improvements would require 
an update to the Cygwin portion.

I would love to have somebody interested in trying out FUSE on Cygwin.  If you 
require a cygfuse package I guess the first step for that would be for me to 
reissue the ITP and make the package real.  Another alternative would be for you 
to build from the Github repo https://github.com/mgeisert/cygfuse if you're 
feeling adventurous.

..mark

Re: fuse

[Mark Geisert]

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 to have somebody interested in trying out FUSE on Cygwin.  If you 
> require a cygfuse package I guess the first step for that would be for me to 
> reissue the ITP and make the package real.  Another alternative would be for you 
> to build from the Github repo https://github.com/mgeisert/cygfuse if you're 
> feeling adventurous.

Our fuse package as it stands is not ready for use.  When I last looked at it 
years ago I was too new to both FUSE and project porting to understand what was 
missing.  Currently it's a source package that supplies a glue layer for Cygwin 
apps to make use of WinFSP, a Windows FUSE driver.  It also supplies source for a 
Cygwin sshfs app that demonstrates correct operation of WinFSP via Cygwin.

I've now looked at and installed the most recent WinFSP.  The Cygwin glue layer 
works as well as it always had.  But something is missing: integration with the 
usual shell file manipulation commands.  For example, one can't 'cd' into the 
directory on which a foreign file system has been loaded.  That seems like a major 
issue unless I'm misunderstanding things.

Let me reach out to the WinFSP folks and see if I'm doing something wrong or if 
there's additional work to be done on the Cygwin side.  In any case the project 
needs some smartening up.  I plan to rename it FUSE for the upcoming ITP, to avoid 
name conflict with libfuse* common on Linux.

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.
Thanks for reading; advice welcome,

..mark

Re: fuse

[ASSI]

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 package (libusb
IIRC) that requires non-standard Windows drivers for functioning fully
or correctly.  How to present that requirement in setup is another
question.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf microQ V2.22R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Re: fuse

[Jon Turney]

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 there is at least one other package (libusb
> IIRC) that requires non-standard Windows drivers for functioning fully
> or correctly.  How to present that requirement in setup is another
> question.

The 'message:' line in the .hint file (see [1]) can be used for a 
related purpose of telling people that Windows drivers are needed, 
although in fact this is only used by libusb0 at the moment.

Actually checking for those being installed generically in setup seems 
fraught.  But I guess you could write a postinstall script which checks 
somehow for it's presence and fails if it's not present?

[1] https://cygwin.com/packaging-hint-files.html

Re: fuse

[Mark Geisert]

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 drivers.
>>
>> No they should not, although there is at least one other package (libusb
>> IIRC) that requires non-standard Windows drivers for functioning fully
>> or correctly.  How to present that requirement in setup is another
>> question.
> 
> The 'message:' line in the .hint file (see [1]) can be used for a related purpose 
> of telling people that Windows drivers are needed, although in fact this is only 
> used by libusb0 at the moment.
> 
> Actually checking for those being installed generically in setup seems fraught.  
> But I guess you could write a postinstall script which checks somehow for it's 
> presence and fails if it's not present?
> 
> [1] https://cygwin.com/packaging-hint-files.html

I had seen "message:" there on [1] and tried once to make use of it, but failed. 
 From reading cygport's pkg_pkg.cygpart, it seemed to me that a 'MESSAGE="foo"' 
line in the cygfuse.cygport file should cause a 'message: cygfuse "foo"' to be 
emitted to the .hint file.  That didn't seem to happen.  Maybe I goofed.

I then thought about manually adding the "message: ..." line, but then realized I 
had two full 75-char lines of info to display and did not know if that was too big 
or what it would look like.  I dropped the idea for the time being and went with 
an Overview section on the package update announcement instead.

I should look at libusb.cygport; thanks Achim for that reminder.
Regards,

..mark

Re: fuse

[Mark Geisert]

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 at and installed the most recent WinFSP.  The Cygwin glue layer 
> works as well as it always had.  But something is missing: integration with the 
> usual shell file manipulation commands.  For example, one can't 'cd' into the 
> directory on which a foreign file system has been loaded.  That seems like a major 
> issue unless I'm misunderstanding things.

This turned out to be an issue in Cygwin 3.3.3 but not 3.3.4 or the upcoming 
3.4.0.  WinFSP is ready to be used from Cygwin.

> I plan to rename it FUSE for the upcoming ITP, to avoid
> name conflict with libfuse* common on Linux.

Nah, there will be two upcoming ITPs, cygfuse and sshfs.  The first will provide 
the glue layers (libfuse and libfuse3) that ride on top of WinFSP, and also a 
'fusermount' command.  The second ITP will be a port of the latest sshfs reference 
implementation to Cygwin.  sshfs is known to clean-compile against the glue layer 
already.

..mark