Windows and Cygwin support

[s-m-e]

@billziss-gh Please correct me if I am wrong: All relevant changes to fuse.py and fusell.py for Windows and Cygwin support were merged into fusepy through fusepy#110 and fusepy#107? I have been going back and forth through diff's of fusepy's head and your fork's head, but I could not spot any other relevant difference.

[billziss-gh]

I just spent some time comparing the master branch in fusepy and the master branch in my fork of fusepy (billziss-gh/fusepy).

It appears that the only change that has not been included is a couple of WinFsp extra capabilities:

• FSP_FUSE_CAP_CASE_INSENSITIVE: advertise the file system as case-insensitive. Supported by both WinFsp and OSXFUSE.
• FSP_FUSE_CAP_READDIR_PLUS: WinFsp supports a form of "enhanced" readdir, where the full stat structure is filled and reported to the FUSE layer during a readdir call. On Windows this results in significant performance improvements, because the Windows "read directory" operation expects to receive name + stat operation in a single call. (FUSE3 has added this capability as well, although in a different manner than WinFsp does it in its FUSE2 API. It should be noted that WinFsp supports the FUSE3 API as well.)

[billziss-gh]

Link to the relevant code in my fusepy fork:

https://github.com/billziss-gh/fusepy/blob/master/fuse.py#L522-L527

[billziss-gh]

I should also add that WinFsp (and OSXFUSE) includes the ability to get and set file flags (i.e. Windows file attributes, such as System, Hidden, etc.) I never added this capability to my fork of fusepy, but you may want to add it to refuse as a few Windows using people have asked for it.

[s-m-e]

@billziss-gh Thanks. I am trying to break this into separate issues, #19 being the first one.

[s-m-e]

@billziss-gh Just for clarification, looking at its headers, it appears to me that WinFsp does not support FUSE's low level API. There is also no Windows-specific code in fusell.py / low.py. Is this correct?

[billziss-gh]

Yes, at this time the low level API is not supported.

The original reason for this was that it was very different from how the Windows file system works and it made little sense for Windows. With the advent of WSL I may actually look into supporting it at some point.

[s-m-e]

@billziss-gh Ok, thanks. WSL 2 was just released. This thing is becoming interesting indeed ...

I just reorganized the list of supported platforms within README.md into something like a matrix. Please check. I am just blindly guessing that Windows on ARM is not supported.

[billziss-gh]

Yes. It should not be hard to port WinFsp (likely just a recompile), but nobody ever asked for it.

[billziss-gh]

Looking at the matrix:

• Windows: None of the low-level API are supported. The FUSE3 high-level API's are supported on x86 and x64 only.

• OpenBSD: I do not believe they have low-level support or any FUSE3 support. But I speak from memory and things may have changed.

• macOS: Looks correct.

• FreeBSD: Libfuse runs on FreeBSD and it naturally has FUSE3 support. I am fairly certain of this as I fixed a problem with rename on FreeBSD about a year ago.

[s-m-e]

Thanks again.

* Windows: None of the low-level API are supported. The FUSE3 high-level API's are supported on x86 and x64 only.

Fix. My bet. I mixed it up when I converted the table to HTML.

* OpenBSD: I do not believe they have low-level support or any FUSE3 support. But I speak from memory and things may have changed.

Correct. Same mistake. I merged OpenBSD support from fusepyng.

* FreeBSD: Libfuse runs on FreeBSD and it naturally has FUSE3 support. I am fairly certain of this as I fixed a problem with `rename` on FreeBSD about a year ago.

refuse / fusepy has not picked it up ... hence no support yet.