DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:subject:to:references:from:message-id:date
	:mime-version:in-reply-to:content-type
	:content-transfer-encoding; q=dns; s=default; b=D81Dhxs8UwV/f3My
	gSciEEnJpM0sNE0VPaHI/7KBM3niXKwnu361el9tE0ojzZIOf2sQp40aWyXlWwQ+
	ZBZQ0Pkya1P3VNrMTYYsvv63X59wPNnQ1iPbPttqNYrI6/EwEir3aOUN+q8DieI2
	tyxkmaG39BAjssGg5I32gTgtdw8=
Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm
Sender: cygwin-owner@cygwin.com
Mail-Followup-To: cygwin@cygwin.com
Subject: FUSE for Cygwin - was: Re: Fork and Windows Heap
To: cygwin@cygwin.com
References: <D3879734.9284%billziss@navimatics.com>
From: Herbert Stocker <hersto@gmx.de>
Message-ID: <57636BD6.3080305@gmx.de>
Date: Fri, 17 Jun 2016 05:17:42 +0200
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:38.0) Gecko/20100101 Thunderbird/38.1.0
MIME-Version: 1.0
In-Reply-To: <D3879734.9284%billziss@navimatics.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

On 16.06.2016 08:37, Bill Zissimopoulos wrote:
>
> I am not porting anything from UNIX. I have a Windows solution developed
> using Visual Studio and the Windows Driver Kit that I am building a FUSE
> compatibility layer for. My DLL is not a Cygwin DLL. It is a native
> Windows DLL that also has a FUSE compatibility layer. I am taking pains to
> make that FUSE compatibility layer available to both Win32 and Cygwin apps.
>

Hey Bill,

this is a GREAT piece of work.
Although i did not dive into kernel development, i do understand that
writing a file system driver for Windows is surely lots of painful work,
with its undocumented and grown API.

You should write a book documenting all the knowledge you gathered
through your research, if the only one available is from '97 as you say.

Really, great work.
Also that you add the FUSE API.

Having FUSE available for Cygwin and maybe for Windows apps is something
i longed for, too. And i thought about adding it to Cygwin. Seariously.
But i'm too constrained to manage that amount of work. :-(

What is FUSE:
   Architecturally a FUSE file system is a (usermode) process that regis-
   ters with the kernel for a certain path in the file system and then
   responds to requests like open file, read/write data, rename file,
   stat file.

So, how is your architecture of the FUSE part of WinFsp?
Are you porting libfuse to Cygwin, so that a Cygwin process can link to
it and instead of receiving requests via /dev/fuse fro the Linux kernel,
your libfuse will receive IRPs through your user mode DLL from your
Windows kernel driver FSD?

Are you planning to have FUSE file systems be ported to native Windows
apps, i.e. don't link with cygwin1.dll, or will they run in a Cygwin
environment?
If porting to native app, this would be easier for the user to install
them, but:
  - FUSE has bindings to many languages like Perl, PHP, etc. Will these
    work then?
  - Aren't the FUSE programs relying on Posix features too much?
    Can they be easily ported with e.g. MinGW?

How are you dealing with limitations of the Windows file system as seen
from a POSIX perspective? You say you can't support hard links.
How will a Cygwin program see symlinks exported by the FUSE file system?
And pipes?

You write that you are mapping
  - characters not supported by Win32 but by POSIX via the Unicode
    private use page
  - Security apspects (SID vs. uid/gid, ACL)
between POSIX and Windows and that you do it like Cygwin/SFU/SFM is
doing it.

But if that's done by your code, a Cygwin process may see slightly
different mappings through WinFsp and through Cygwin. Won't that be a
potential for Bugs (misbehaving apps) or even for security issues?

i'm looking forward to trying it out this weekend and to see it go
from alpha state to stable.

(And i'm curious about the differences of disk based and network based
file systems. Is it just the handling as seen from the user or also
the semantics.)


Herbert


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple