WinFsp: building Windows file systems as user mode programs

What WinFsp actually solves for Windows developers

On Linux, FUSE lets a normal process present a directory tree to the rest of the system. Windows has no equivalent in the box. Writing a file system driver there means kernel mode code, and the README calls that task notoriously difficult. WinFsp is the missing layer: it lets developers write their own file systems, or Windows drives, as user mode programs without any knowledge of Windows kernel programming.

The audience is narrow and specific. It is for people who have data that is not already a file system and want Windows applications to reach it through the standard Windows file API, without those applications knowing anything about the storage behind it. The README frames this as the core benefit: any information or storage may be organized and presented as a file system, and then any Windows application can read it with ordinary file calls. If you are building an archive browser, a remote protocol client, a versioned store or a virtual drive, that is the target use. If you just want to see a remote directory in Explorer, you are not the audience for the API, though you may still be a user of something built on it.

The kernel driver, the DLL and the call path between them

The architecture is two pieces. The core WinFsp consists of a kernel mode file system driver, the FSD, and a user mode DLL. The FSD interfaces with the Windows kernel and handles the interactions required to present itself as a file system driver. The DLL interfaces with the FSD and exposes an API that handles file system functions.

The data flow is request and callback. When an application opens a file, the file system receives an Open call carrying the necessary information. Your user mode code answers that call. The kernel side keeps the operating system satisfied; your side implements the semantics. This split is why the project can claim stability without kernel mode crashes, resource leaks or similar problems: the risky code lives in the driver, which you do not write, and the code you do write runs in user space where a mistake is a process failure rather than a bugcheck.

The API surface is deliberately plural. WinFsp includes Native, FUSE2, FUSE3 and .NET APIs, so a file system originally written against FUSE on Linux has a migration path rather than a rewrite. The README also points to a Service Architecture document covering how user mode file systems integrate with the Windows shell, and notes that MEMFS and file systems using the WinFsp Launcher can be started from Explorer through Map Network Drive.

Installing WinFsp and mounting MEMFS as a first test

The README gives one install route: download and run the WinFsp installer from the releases page. In the installer, select the option to install the Developer files. That choice matters, because it brings in the MEMFS sample file system along with the header and library files you need to build your own user mode file system.

Once installed, MEMFS is the quickest way to confirm the driver is working. The README shows it being launched from the command line and mapped to a drive letter:

net use X: \\memfs64\test

The command should complete successfully. From there you can switch to the drive, write a file and read it back, which is exactly the sequence the README demonstrates:

X:
echo "hello world" > hello.txt
dir
type hello.txt

The directory listing should show hello.txt, and type should print hello world. The README's own transcript shows a 28 byte file with a LastWriteTime. When you are finished, the drive is removed the same way it was created:

net use X: /delete

The README notes that MEMFS can also be launched from Explorer using Map Network Drive, so the command line is not the only route. If you plan to distribute a file system, the same document points to the Service Architecture page for the launcher details.

Where WinFsp is the wrong tool

WinFsp is a platform, not an end user product. The README installs a driver and developer files; it does not mount your S3 bucket, your SFTP server or your encrypted vault. Those come from other projects that build on WinFsp, and if that is your need, installing WinFsp alone leaves you with MEMFS and nothing else.

The second boundary is the driver itself. A kernel mode file system driver is a system component, and installing one changes what the machine can do at a level ordinary applications do not reach. The README does not document uninstall steps, rollback behaviour or interaction with third party security software, so those are questions to answer before deployment rather than after. That gap is not unusual for a project of this shape, but it is a real one, and it is the reason a first install belongs on a test machine.

The third is version scope. The README states support for Windows 7 to Windows 11 across x86, x64 and ARM64. Windows 7 is old enough that some readers will be running something the README does not name at all, and for those the documentation is simply silent. WinFsp is also the wrong choice if your data is already a file system on a local disk. There is nothing to proxy.

WinFsp against SSHFS-Win and rclone

The most common alternatives people reach for are not competitors so much as consumers. SSHFS-Win and rclone both need something to present a remote server or object store as a Windows drive, and WinFsp is one of the things that can do that presenting. The difference in approach is where the file system logic lives. With SSHFS-Win or rclone, you install a finished file system and point it at a host or a remote. With WinFsp, you write the file system yourself against the Native, FUSE2, FUSE3 or .NET API and decide what every Open, read and write means.

That makes the choice mostly about whether the file system you want already exists. If it does, the finished tool is less work and less risk. If it does not, or if you need semantics the existing tool does not offer, WinFsp is the layer you build on. There is a middle case worth naming: a FUSE file system you already maintain on Linux. The FUSE2 and FUSE3 APIs exist so that code has somewhere to go, which is a different proposition from starting from nothing.

Licence, releases and what maintenance costs

WinFsp is available under the GPLv3 licence with a special exception for Free/Libre and Open Source Software, and a commercial licence is also available through the contact address given in the README. The repository's licence field is not a standard SPDX identifier, so if licence terms decide your adoption, read License.txt in the repository rather than trusting a label. Nothing here is legal advice; the exception is the part worth reading closely, because it is what makes the GPLv3 workable for some closed source products and not others.

On maintenance, the last push to the repository was on 2026-09-18, and the most recent release listed is v2.2B4 (WinFsp 2026 Beta4) from 2026-08-03, preceded by v2.2B3 and v2.2B2 in July 2026. Note the naming: the recent releases are betas, so a team that needs a stable line should check what the stable release channel offers before pinning a version. Upgrading means replacing a kernel driver on every machine that runs your file system, which is a heavier operation than swapping a library. The README describes WinFsp as self-contained with no external dependencies, which reduces the surface you have to coordinate, but it does not remove the driver replacement step from your deployment plan.

Editorial conclusion

Adopt WinFsp when you need a real Windows drive backed by your own storage or protocol and you can write to the Native, FUSE2, FUSE3 or .NET API it exposes. Do not adopt it if you only want to mount a remote server on one machine, where SSHFS-Win or rclone already ship the file system for you. Before committing, verify that the installer you downloaded is signed and comes from the winfsp/winfsp releases page, that you selected the Developer files so MEMFS and the headers are present, and that your target Windows version and architecture are covered by the Windows 7 to Windows 11, x86, x64 and ARM64 support the README lists.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. winfsp/winfsp on GitHub