WinFsp – Windows File System Proxy(github.com)
github.com
WinFsp – Windows File System Proxy
https://github.com/billziss-gh/winfsp
54 comments
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).
Oh, it has a FUSE compat layer too, that's pretty damn cool.
You can even implement a fuse server in cygwin, so many fuse implementations will straight forward compile from my experience.
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.)
(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.)
> You might not even need that if WinFSP provides signed binaries and you don't modify the driver part.
The README.md which the submission linked says that they do indeed provide signed binaries for every release.
The README.md which the submission linked says that they do indeed provide signed binaries for every release.
As for using it to create a new file system, the repository has a basic tutorial for that: https://github.com/billziss-gh/winfsp/blob/master/doc/WinFsp...
> 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.
> 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.
And then it is GPL with exception for libre software or commercial license.
I hope they have reasonable commercial licensing.
I hope they have reasonable commercial licensing.
APFS (Apple Filesystem) on MacOS has some kind of file provider API too. Here's one app that uses it:
https://www.expandrive.com/strongsync/
https://www.expandrive.com/strongsync/
In most of the benchmarks down it outperforms NTFS. What’s going on there?
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...
BitFort sounds interesting - is the source code available?
Also, what did you use to build your awesome looking resume page? https://resume.sam0x17.dev/ :)
Also, what did you use to build your awesome looking resume page? https://resume.sam0x17.dev/ :)
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.
If I were to re-write I would do it in Rust for sure.
I see. I was asking simply because I was interested in learning interesting things from the actual source code instead of actually running it :)
If you are interested in sharing it privately, let me know and I'll email you!
If you are interested in sharing it privately, let me know and I'll email you!
Thank you I actually used a template that was posted on HN years ago https://github.com/Thomashighbaugh/resume
That page does look pretty awesome!
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.
[0] https://github.com/billziss-gh/winfsp/blob/master/doc/WinFsp...
[0] https://github.com/billziss-gh/winfsp/blob/master/doc/WinFsp...
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.
Are there any ready to use file system implementations available?
http://www.secfs.net/winfsp/doc/Known-File-Systems/
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).
Maybe I'll give SSHFS another try again now...
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).
Maybe I'll give SSHFS another try again now...
SSHFS has behaved a little jankily for me on Linux, too, since forever. I wonder if the protocol’s just not really up to the 2%.
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.
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.
rclone - https://rclone.org/ uses this IIRC. Can mount a heck of a lot of things!
[deleted]
i'd love one for keepass and https://www.presslabs.com/docs/code/gitfs/ :)
What should that actually do? Expose passwords as files?
This might be handy for passing files to a virtual machine if you don't want to use Virtualbox's 'guest additions' software
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.
I found https://github.com/pfpacket/rust-9p to be reasonably good and easy to hack on. My fork (https://github.com/piscisaureus/rust-9p) has some patches to improve support for the 9P2000.W dialect used by Windows.
Why wouldn't you want to use the VirtualBox guest additions?
It's GPLv2 licensed and brings additional features that make using the VM easier.
You might not want to be locked in. I've used VirtualBox to build systems meant to eventually run elsewhere.
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.
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.
They are always rock solid for me on Windows guests. Linux guests are a different matter altogether, but mainly due to permissions.
So other than having FUSE compatibility, why this rather than Dokan?
I played with Dokan in its early days. It was promising, but I found it a little buggy. (Not sure if that remained true once it matured more)
A benchmark from nearly five years ago means nothing today.
Windows already has similar native APIs, why bother with this?
Out of curiosity: what sort of apis are we talking about?
Maybe this one?
> "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...
> "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).
And forget about advanced stuff like mmap
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).
And forget about advanced stuff like mmap
It also has a FUSE compat layer which maybe useful when porting existing *nix software
Ah ok.
> 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.
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.
Cool, the third version of FUSE for Windows …
https://github.com/billziss-gh/sshfs-win/releases/tag/v3.5.2...