From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 112995 invoked by alias); 5 Sep 2016 20:16:48 -0000 Mailing-List: contact cygwin-apps-help@cygwin.com; run by ezmlm Precedence: bulk Sender: cygwin-apps-owner@cygwin.com List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Mail-Followup-To: cygwin-apps@cygwin.com Received: (qmail 112983 invoked by uid 89); 5 Sep 2016 20:16:47 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.4 required=5.0 tests=AWL,BAYES_05,KAM_LAZY_DOMAIN_SECURITY autolearn=no version=3.3.2 spammy=UD:cygport, connector, H*Ad:U*mark, fuse X-HELO: m0.truegem.net Received: from m0.truegem.net (HELO m0.truegem.net) (69.55.228.47) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 05 Sep 2016 20:16:45 +0000 Received: (from daemon@localhost) by m0.truegem.net (8.12.11/8.12.11) id u85KGhNR071812 for ; Mon, 5 Sep 2016 13:16:43 -0700 (PDT) (envelope-from mark@maxrnd.com) Received: from 76-217-5-154.lightspeed.irvnca.sbcglobal.net(76.217.5.154), claiming to be "[192.168.1.100]" via SMTP by m0.truegem.net, id smtpdzhllrx; Mon Sep 5 13:16:39 2016 Subject: Re: [ITP] FUSE 2.8 To: cygwin-apps@cygwin.com References: <579A4102.9040406@maxrnd.com> <20160728200435.GG26311@calimero.vinschen.de> <20160729085141.GK26311@calimero.vinschen.de> <20160817091433.zksukafls6mkk52u@calimero.vinschen.de> <57CD3C7A.1000902@maxrnd.com> From: Mark Geisert Message-ID: <57CDD2A6.8010008@maxrnd.com> Date: Mon, 05 Sep 2016 20:16:00 -0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:43.0) Gecko/20100101 Firefox/43.0 SeaMonkey/2.40 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2016-09/txt/msg00004.txt.bz2 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