This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

FUSE for Cygwin - was: Re: Fork and Windows Heap

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
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.)


Problem reports:
Unsubscribe info:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]