FUSE for Cygwin

[Herbert Stocker]

On 6/17/2016 9:25 AM, Bill Zissimopoulos wrote:
> WinFsp provides three (3) different modes of integration:
>
> (1) Its own native API, which allows a user mode file system to do almost
> anything NTFS can do (with a few exceptions). It also allows for the
> Read, Write and ReadDirectory callbacks to be asynchronous (return
> STATUS_PENDING). I recommend this API for file systems that want maximum
> performance and integration with Windows.
>
> (2) A FUSE (high-level) API for Win32 (i.e. non-Cygwin) applications. This
> is useful if one has a FUSE file system that they can easily port to
> Windows or they do not want any Cygwin dependencies.
>
> (3) A FUSE (high-level) API for Cygwin. As you correctly note many FUSE
> file systems are too POSIX specific (as they were born on Linux/OSX) and
> they only make sense in a Cygwin environment.
>
> I expect that most FUSE file systems will probably go for option (3)
> initially. Then they may want to consider going to (2) if they can
> easily port their core file system code to Windows. Then they may even
> consider (1) if they have needs that the FUSE API cannot support (e.g.
> full support for Windows ACL's).

Hi Bill,

i'm planning to make a suggestion of mode (4). It will be in addition or
instead of (3) and will avoid those issues we touched.
But i can't do it earlier than Saturday evening.

Of course i did read your website before posting this, don't know why i
asked that question about your design this way though.

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