From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 65954 invoked by alias); 28 Jul 2016 17:29:51 -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 65876 invoked by uid 89); 28 Jul 2016 17:29:51 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.6 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY autolearn=no version=3.3.2 spammy=Wont, Won't, H*r:ip*192.168.1.100, pacific 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 (AES256-SHA encrypted) ESMTPS; Thu, 28 Jul 2016 17:29:49 +0000 Received: (from daemon@localhost) by m0.truegem.net (8.12.11/8.12.11) id u6SHTl4E064950 for ; Thu, 28 Jul 2016 10:29:47 -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 smtpdUsKHBr; Thu Jul 28 10:29:38 2016 Subject: Re: [ITP] FUSE 2.8 To: cygwin-apps@cygwin.com References: <20160723104021.GA18159@calimero.vinschen.de> <20160723174836.GD11373@calimero.vinschen.de> <20160725073538.GF11373@calimero.vinschen.de> <5799CDB4.2000706@maxrnd.com> From: Mark Geisert Message-ID: <579A4102.9040406@maxrnd.com> Date: Thu, 28 Jul 2016 17:29:00 -0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:42.0) Gecko/20100101 Firefox/42.0 SeaMonkey/2.39 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-07/txt/msg00096.txt.bz2 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