Re: [ITP] FUSE 2.8
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
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
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
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
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
