yeonsh
82f59837f6
Under heavy concurrent rename + change-notification load a volume can deadlock permanently: all renames (exclusive) and opens (shared) on the volume block, freezing the mount. FspFileSystemNotifyBegin (FspVolumeNotifyLock) acquires the per-volume FileRenameResource shared via an owner pointer (&VolumeNotifyCount) and holds it for the whole Begin/End session. If a rename queues as an exclusive waiter mid-session, the asynchronous FspVolumeNotifyWork then re-acquires the same resource shared with ExAcquireResourceSharedLite. Due to ERESOURCE writer-priority that shared acquire blocks behind the queued exclusive waiter (the worker thread is not the owner -- the owner is the &VolumeNotifyCount pointer). But that work item is the one that must process FspFileSystemNotifyEnd to drop VolumeNotifyCount to 0 and release the session, so it can never run: the session lock is never released and the rename waits forever, while VolumeNotifyCount runs away as Begin keeps incrementing it. Acquire the rename resource in FspVolumeNotifyWork with ExAcquireSharedStarveExclusive instead. The enclosing Begin/End session already holds the resource shared and already defers renames until End, so granting this redundant shared acquire ahead of the queued exclusive waiter preserves name-stability semantics while breaking the deadlock. A real exclusive holder still blocks the starve-exclusive acquire, so correctness is unchanged.
WinFsp · Windows File System Proxy
WinFsp enables developers to write their own file systems (i.e. "Windows drives") as user mode programs and without any knowledge of Windows kernel programming. It is similar to FUSE (Filesystem in Userspace) for Linux and other UNIX-like computers.
winfsp.dev
Overview
WinFsp is a platform that provides development and runtime support for custom file systems on Windows computers. Typically any information or storage may be organized and presented as a file system via WinFsp, with the benefit being that the information can be accessed via the standand Windows file API’s by any Windows application.
The core WinFsp consists of a kernel mode file system driver (FSD) and a user mode DLL. The FSD interfaces with the Windows kernel and handles all interactions necessary to present itself as a file system driver. The DLL interfaces with the FSD and presents an API that can be used to handle file system functions. For example, when an application attempts to open a file, the file system receives an Open call with the necessary information.
Using WinFsp to build a file system has many benefits:
Easy development: Developing kernel mode file systems for Windows is a notoriously difficult task. WinFsp makes file system development relatively painless. This Tutorial explains how to build a file system.
Stability: Stable software without any known kernel mode crashes, resource leaks or similar problems. WinFsp owes this stability to its Design and its rigorous Testing Regime.
Correctness: Strives for file system correctness and compatibility with NTFS. For details see the Compatibility document.
Performance: Has excellent performance that rivals or exceeds that of NTFS in many file system scenarios. Read more about its Performance.
Wide support: Supports Windows 7 to Windows 11 and the x86, x64 and ARM64 architectures.
Flexible API: Includes Native, FUSE2, FUSE3 and .NET API's.
Shell integration: Provides facilities to integrate user mode file systems with the Windows shell. See the Service Architecture document.
Self-contained: Self-contained software without external dependencies.
Widely used: Used in many open-source and commercial applications with millions of installations (estimated: the WinFsp project does not track its users).
Flexible licensing: Available under the GPLv3 license with a special exception for Free/Libre and Open Source Software. A commercial license is also available. Please contact Bill Zissimopoulos <billziss at navimatics.com> for more details.
Installation
Download and run the WinFsp installer. In the installer select the option to install the "Developer" files. These include the MEMFS sample file system, but also header and library files that let you develop your own user-mode file system.
Launch a file system for testing
You can test WinFsp by launching MEMFS from the command line:
billziss@xps ⟩ ~ ⟩ net use X: \\memfs64\test
The command completed successfully.
billziss@xps ⟩ ~ ⟩ X:
billziss@xps ⟩ X:\ ⟩ echo "hello world" > hello.txt
billziss@xps ⟩ X:\ ⟩ dir
Directory: X:\
Mode LastWriteTime Length Name
---- ------------- ------ ----
-a---- 6/12/2022 5:15 PM 28 hello.txt
billziss@xps ⟩ X:\ ⟩ type hello.txt
hello world
billziss@xps ⟩ X:\ ⟩ cd ~
billziss@xps ⟩ ~ ⟩ net use X: /delete
X: was deleted successfully.
MEMFS (and all file systems that use the WinFsp Launcher as documented in the Service Architecture document) can also be launched from Explorer using the "Map Network Drive" functionality.
Resources
Documentation:
Discussion: