In case anyone is wondering: if you want to use sshfs network drives as demoed on their Github page, WinFsp is not enough, you need to also install SSHFS-Win:
Haven't tried the latest versions of WinFsp + SSHFS-Win, glad to see a new GUI for the later and new versions. My experience is good but if you have an unstable connection, the mapped drive didn't reconnect by itself at all times. For a better experience I've always relied on RaiDrive (free with Ads) or SFTP Drive from N software (free for non-commercial)
Used this extensively when I was working on BitFort (abandoned project). It's really solid. If you're open source you can use the whole thing no problem. If you're closed source, a commercial license costs around $5k.
It's interesting to note that WSL uses 9p to mount the filesystem on Windows. Had MSFT taken a more FOSS-friendly approach, we could've had a burgeoning FUSE ecosystem built around 9p.
The WSL team in their GitHub have teased experiments with allowing the 9p server to do more outside of WSL and be an open protocol for Windows moving forward. Given Windows' backwards compatibility mandates, you may be able to understand why they are taking a slow and deliberate exploration process to figure out how much that is something they want to support in Windows moving forward (especially if it escapes the realm of "developer tools" where they feel they have more freedom).
Could one easily distribute software that bundles this and have it installed by novice end users? What kind of permission granting seances would they have to go through, if any?
You probably can and it won't be nearly as bad as what it is on MacOS. You only need a code signing certificate for drivers from Microsoft. You might not even need that if WinFSP provides signed binaries and you don't modify the driver part.
(Source: until 2 years ago I used to work at a company that did that using a proprietary driver - CBFS - and was looking at WinFSP to replace it.)
> What kind of permission granting seances would they have to go through, if any?
From personal experience of using this: WinFSP have ready .msi installer. After going through the standard process of installing it, then you need to install the file system implementation you want (for example SSHFS from http://www.secfs.net/winfsp/rel/).
The required permissions amount to the standard installation prompt, at least from my experience on Windows 10.
It turns out it's actually very easy to outperform off-the-shelf file systems depending on what your metric is. I discovered this when I was developing BitFort (abandoned project) which made use of WinFsp on Windows and pure FUSE on Linux. In my case the secret was having all the paths available in a fast in-memory data structure. I was dealing with a remote cloud file system, yet I was able to open up folders and browse around the file system faster than NTFS can with LOCAL file systems because every path and the MIME type is already in memory. For some applications (i.e. if you have trillions of small files) this might be a memory hog but for most I imagine it would be just fine. Seems like something OSes should have a toggleable option for...
I've been toying with the idea of releasing the bitfort source code as open source, but the usefulness is limited as it only worked with a very specific version of Node back in 2018 and the key dependencies (in particular the FUSE one) no longer works.
If I were to re-write I would do it in Rust for sure.
According to the docs [0] it's in part due to an unequal comparison: "[WinFsp] outperforms NTFS in most scenarios (an unfair comparison as NTFS is a disk file system and WinFsp is tested with an in-memory file system)." I guess the point is just that WinFsp is fast enough for practical use.
Yeah, I assumed it was going to be an in-memory comparison but that’s super misleading and doesn’t let one get a sense of the overhead of the system itself.
As mentioned in other comments it is an unequal comparison, but it's easy to outperform NTFS on Windows as the NTFS driver has some serious lock contention issues that make directory enumeration slow.
I've personally only used SSHFS (years ago). It was ok - slightly flakey for me. I can't remember what was wonky, but it was like 98% working, I couldn't figure out the last bit, so I just switched to straight up SMB/samba (I had pretty free control of the remote end, so that was a reasonable solution).
Same in my experience, but SFTP itself isn't exactly great either. Especially when your connection is less than ideal and you're working with large-ish files.
SMB tunneled over SSH works better in many cases, but of course that has it's own set of problems and is a huge pain to set up.
Actually WSL2 might be a better target as it would enable some tweaking of the mapping. Did anyone have success implementing virtio communication through hyperv and mount e.g. a custom p9fs. E.g. to support ownership and attributes. What would be the best p9fs server to start with? I had limited success with p9fs on winfsp from cygwin some time ago due to the problems of mapping effective access rights correctly.
It's an absolute disaster for one. I haven't actually managed to get shared folders to work reliably in years. It ended up being faster and more reliable to run Samba on the host and connect over a virtual network.
Some of the other features of course can't easily be duplicated with other tools and they work decent-ish anyways so there's no reason to try, but shared folders aren't one of them.
> "The Windows Projected File System (ProjFS) allows a user-mode application called a "provider" to project hierarchical data from a backing data store into the file system, making it appear as files and directories in the file system. For example, a simple provider could project the Windows registry into the file system, making registry keys and values appear as files and directories, respectively. An example of a more complex provider is VFS for Git, which is used to virtualize very large git repos." - https://docs.microsoft.com/en-us/windows/win32/projfs/projec...
or this one?
> "Starting in Windows 10, version 1709, Windows provides the cloud files API. This API consists of several native Win32 and WinRT APIs that formalize support for cloud sync engines, and handles tasks such as creating and managing placeholder files and directories." - https://docs.microsoft.com/en-us/windows/win32/cfapi/cloud-f...
Neither is a generic user space vfs API. They are only tailored to some narrow use cases with bunch of limitations.
Last time I checked projfs can't stream files from memory while cloudfs can't stream directories from memory (i.e. you have to pre-create placeholder files in local fs).
> It outperforms NTFS in most scenarios (an unfair comparison as NTFS is a disk file system and WinFsp is tested with an in-memory file system)
Oh good grief! Let me guess, they first benchmarked it against a ram disk, but the resulting graphs didn't look so impressive so they scrapped that and decided to benchmark it against a disk, which they admit was unfair, just to get the impressive looking graphics.
https://github.com/billziss-gh/sshfs-win/releases/tag/v3.5.2...