This is the mail archive of the
mailing list for the Cygwin project.
Re: FUSE for Cygwin
- From: Herbert Stocker <hersto at gmx dot de>
- To: cygwin at cygwin dot com
- Date: Fri, 17 Jun 2016 16:08:18 +0200
- Subject: Re: FUSE for Cygwin
- Authentication-results: sourceware.org; auth=none
- References: <D388F238 dot 929F%billziss at navimatics dot com>
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).
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.
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple