sys: FspFileNodeTrySetFileInfoOnOpen

Changelog.asciidoc

@@ -1,5 +1,18 @@
 = Changelog
 
+
+v1.1 (2017.1)::
+
+This release brings some major new components and improvements.
+
+- A .NET layer that allows the creation of file systems in managed mode. This is contained in the new `winfsp-msil.dll`. The new .NET layer is being tested with the WinFsp test suites and Microsoft's ifstest.
+- FUSE for Cygwin is now included with the installer.
+- FUSE now has a `-ovolname=VOLNAME` parameter that allows setting the volume label. Thanks @samkelly.
+- A number of other FUSE improvements have been made (see issue #85).
+
+NOTE: The C++ layer included in the v1.1 beta releases is not part of this release as it is still work in progress. It can be found in `inc/winfsp/winfsp.hpp` in the WinFsp source repository.
+
+
 v1.1B3 (2017.1 B3)::
 
 v1.1B2 (2017.1 B2)::

build/VStudio/installer/Product.wxs

@@ -252,9 +252,9 @@
                 <Component Id="C.winfsp.h">
                     <File Name="winfsp.h" KeyPath="yes" />
                 </Component>
-                <Component Id="C.winfsp.hpp">
+                <!--Component Id="C.winfsp.hpp">
                     <File Name="winfsp.hpp" KeyPath="yes" />
-                </Component>
+                </Component-->
             </Directory>
             <Directory Id="INCDIR.fuse" Name="fuse">
                 <Component Id="C.fuse.h">
@@ -350,7 +350,7 @@
                     <File Name="passthrough.vcxproj.filters" KeyPath="yes" />
                 </Component>
             </Directory>
-            <Directory Id="SMPDIR.passthrough_cpp" Name="passthrough-cpp">
+            <!--Directory Id="SMPDIR.passthrough_cpp" Name="passthrough-cpp">
                 <Component Id="C.passthrough_cpp.cpp">
                     <File Name="passthrough-cpp.cpp" KeyPath="yes" />
                 </Component>
@@ -363,7 +363,7 @@
                 <Component Id="C.passthrough_cpp.vcxproj.filters">
                     <File Name="passthrough-cpp.vcxproj.filters" KeyPath="yes" />
                 </Component>
-            </Directory>
+            </Directory-->
             <Directory Id="SMPDIR.passthrough_fuse" Name="passthrough-fuse">
                 <Component Id="C.passthrough_fuse.c">
                     <File Name="passthrough-fuse.c" KeyPath="yes" />
@@ -454,7 +454,7 @@
         <ComponentGroup Id="C.WinFsp.inc">
             <ComponentRef Id="C.fsctl.h" />
             <ComponentRef Id="C.winfsp.h" />
-            <ComponentRef Id="C.winfsp.hpp" />
+            <!--ComponentRef Id="C.winfsp.hpp" /-->
             <ComponentRef Id="C.fuse.h" />
             <ComponentRef Id="C.fuse_common.h" />
             <ComponentRef Id="C.fuse_opt.h" />
@@ -482,10 +482,10 @@
             <ComponentRef Id="C.passthrough.sln" />
             <ComponentRef Id="C.passthrough.vcxproj" />
             <ComponentRef Id="C.passthrough.vcxproj.filters" />
-            <ComponentRef Id="C.passthrough_cpp.cpp" />
-            <ComponentRef Id="C.passthrough_cpp.sln" />
-            <ComponentRef Id="C.passthrough_cpp.vcxproj" />
-            <ComponentRef Id="C.passthrough_cpp.vcxproj.filters" />
+            <!--ComponentRef Id="C.passthrough_cpp.cpp" /-->
+            <!--ComponentRef Id="C.passthrough_cpp.sln" /-->
+            <!--ComponentRef Id="C.passthrough_cpp.vcxproj" /-->
+            <!--ComponentRef Id="C.passthrough_cpp.vcxproj.filters" /-->
             <ComponentRef Id="C.passthrough_fuse.c" />
             <ComponentRef Id="C.passthrough_fuse.winposix.c" />
             <ComponentRef Id="C.passthrough_fuse.winposix.h" />

build/VStudio/version.properties

@@ -17,8 +17,8 @@
 
         <MyCanonicalVersion>1.1</MyCanonicalVersion>
 
-        <MyProductVersion>2017.1 B3</MyProductVersion>
-        <MyProductStage>Beta</MyProductStage>
+        <MyProductVersion>2017.1</MyProductVersion>
+        <MyProductStage>Gold</MyProductStage>
 
         <MyVersion>$(MyCanonicalVersion).$(MyBuildNumber)</MyVersion>
         <MyVersionWithCommas>$(MyVersion.Replace('.',',')),0</MyVersionWithCommas>

doc/Frequently-Asked-Questions.asciidoc

@@ -10,6 +10,11 @@ I am running Windows 7 and I am finding that the installed driver is not signed.
 	https://technet.microsoft.com/en-us/library/security/3033929.aspx
 
 
+Disconnecting (unmapping) a network drive does not work. [@carlreinke]::
+
+    You may have Dokany installed. Dokany installs its own Network Provider DLL that unfortunately interferes with the WinFsp handling of network drives. The solution is to change your system's Network Provider order and ensure that the WinFsp Network Provider runs before the Dokany one. Instructions on how to change the Network Provider order can be found in this http://blogs.interfacett.com/changing-the-network-provider-order-in-windows-10[article].
+
+
 Why is the DLL not installed in the Windows system directories? [@netheril96]::
 
     It is true that this would make it convenient to load the DLL, because the Windows loader looks into the Windows system directories when it loads DLL's. However, in the opinion of the WinFsp author, software that does not ship with the OS should not be installing components in the system directories.

doc/Home.md

@@ -17,6 +17,7 @@ The documentation available here discusses various aspects of WinFsp.
 
 - The [[Design|WinFsp-Design]] document describes the high-level design of WinFsp.
 - The [[IPC|WinFsp-as-an-IPC-Mechanism]] document offers insights into the WinFsp Inter-Process Communication mechanism.
+- The [[Queued Events|Queued-Events]] document discusses a low-level synchronization primitive that is largely responsible for the excellent performance of the WinFsp IPC mechanism.
 - The [[Service Architecture|WinFsp-Service-Architecture]] document discusses how to intergrate a file system into Windows as a service and the reasons to do so.
 - The [[SSHFS Port Case Study|SSHFS-Port-Case-Study]] document chronicles the creation of the WinFsp-FUSE compatibility layer and the decisions that led to its design.
 

doc/Queued-Events.asciidoc

@@ -0,0 +1,105 @@
+= Queued Events - Windows kernel events with IOCP scheduling characteristics
+
+In this article I am discussing _Queued Events_. _Queued Events_ are a Windows kernel synchronization mechanism that I invented for https://github.com/billziss-gh/winfsp[WinFsp - FUSE for Windows]. _Queued Events_ behave like kernel Synchronization Events (i.e. Win32 auto-reset events), but provide scheduling characteristics similar to those of I/O Completion Ports.
+
+== The Problem
+
+During the later stages of WinFsp development I decided to do some performance testing to understand its behavior and find opportunities for optimization. I found out that WinFsp performed very well in most tested scenarios, but there was one test that seemed to have bad performance for no particular reason.
+
+I ended up profiling this issue using xperf (included in the https://docs.microsoft.com/en-us/windows-hardware/test/wpt/[Windows Performance Toolkit]), which allows for kernel-level profiling. I spent considerable time looking at the profiling results, but could identify no obvious issue with my code.
+
+After a day or two of doing this and being stumped I finally had a lightbulb moment: what if the issue is not with my code, but with how the OS schedules threads? Sure enough I had xperf trace context switches and found that on good runs the OS would context switch my file system threads relatively rarely; on bad runs the OS would context switch my threads excessively.
+
+After contemplating this issue I realized that this was happening because the OS was trying to schedule my threads in a "fair" manner. Windows in general tries to give every thread a chance to run. This can be counter-productive in server-like programs (such as file systems), where all server threads are equivalent and it is actually better to reuse the same thread (if possible) to avoid context switching and other negative effects.
+
+== The Solution
+
+One way of looking at WinFsp is as an IPC (Inter-Process Communication) mechanism. The Windows kernel packages file system operations (open, close, read, write) as IRP's (I/O Request Packets) which it sends to WinFsp. WinFsp places them in an _I/O Queue_; at a later time the threads in a user mode file system retrieve the IRP's from the _I/O Queue_ and service them.
+
+The _I/O Queue_ had gone through multiple iterations, but at the time I was looking at this issue it was using Windows kernel Synchronization Event's (Win32 auto-reset events) for managing threads. The problem was that a wait on a Synchronization Event would be satisfied in a "fair" manner, thus resulting to excessive context switching and bad performance in some circumstances. I needed to find a way to convince Windows to schedule my threads in an "unfair" manner, giving preference to the same thread as much as possible.
+
+I started considering different schemes where I would associate a different event per thread thus being able to wake up the "correct" thread myself and effectively writing my own mini-scheduler. Luckily I had another lightbulb moment: I/O completion ports already do this better than I would ever be able to!
+
+The kernel portion of an I/O Completion Port is called a https://msdn.microsoft.com/en-us/library/windows/hardware/ff549547(v=vs.85).aspx[KQUEUE]. KQUEUE's are (unfortunately) not directly exposed to user mode, however they are at the core of the user mode I/O Completion Ports. KQUEUE's are the main reason I/O Completion Ports are so fast as they provide the following scheduling characteristics:
+
+- They have a Last-In First-Out (LIFO) wait discipline.
+- They limit the number of threads that can be satisfied concurrently.
+
+I briefly considered the idea of building _I/O Queues_ directly on top of KQUEUE's, but soon dismissed this idea because _I/O Queues_ are not simple queues but provide additional services, such as IRP cancelation, IRP expiration, etc.
+
+== Queued Events
+
+In an ideal scenario I wanted to continue using my implementation of _I/O Queues_ which had undergone considerable testing and I knew it worked. But somehow I had to convince the Windows kernel to change the scheduling characteristics of Synchronization Events to mirror those of a KQUEUE.
+
+Then I had lightbulb no 3: _Queued Events_ or how to make a queue behave like a Synchronization Event.
+
+Here is how _Queued Events_ work. A _Queued Event_ consists of a KQUEUE and a spin lock. There is also a single dummy item that can be placed in the KQUEUE.
+
+The KQUEUE is guaranteed to contain either 0 or 1 items. When the KQUEUE contains 0 items the _Queued Event_ is considered non-signaled. When the KQUEUE contains 1 items the _Queued Event_ is considered signaled.
+
+ifdef::env-browser[]
+[ditaa,file="Queued-Events/states.png"]
+--
+        Non signaled                                    Signaled
++---------------------------+                 +---------------------------+
+| Queued Event              |                 | Queued Event              |
++---------------------------+                 +---------------------------+
+|                           |                 |               +---------+ |
+|   KQUEUE        (empty)   |                 |   KQUEUE      |  DUMMY  | |
+|                           |                 |               +---------+ |
++---------------------------+                 +---------------------------+
+--
+endif::env-browser[]
+ifndef::env-browser[image::Queued-Events/states.png[]]
+
+To transition from the non-signaled to the signaled state, we acquire the spin lock and then insert the dummy item in the KQUEUE using https://msdn.microsoft.com/en-us/library/windows/hardware/ff549570(v=vs.85).aspx[KeInsertQueue]. To transition from the signaled to the non-signaled state, we simply (wait and) remove the dummy item from the KQUEUE using https://msdn.microsoft.com/en-us/library/windows/hardware/ff549605(v=vs.85).aspx[KeRemoveQueue] (without the use of the spin lock).
+
+----
+EventSet:
+    AcquireSpinLock
+    if (0 == KeReadState())          // if KQUEUE is empty
+        KeInsertQueue(DUMMY);
+    ReleaseSpinLock
+
+EventWait:
+    KeRemoveQueue();                 // (wait and) remove item
+----
+
+First notice that EventSet is serialized by the use of the spin lock. This guarantees that the dummy item can be only inserted ONCE in the KQUEUE and that the only possible signaled state transitions for EventSet are 0->1 and 1->1. This is how https://msdn.microsoft.com/en-us/library/windows/hardware/ff553253(v=vs.85).aspx[KeSetEvent] works for a Synchronization Event.
+
+Second notice that EventWait is not protected by the spin lock, which means that it can happen at any time including concurrently with EventSet or another EventWait. Notice also that for EventWait the only possible transitions are 1->0 or 0->0 (0->block->0). This is how https://msdn.microsoft.com/en-us/library/windows/hardware/ff553350(v=vs.85).aspx[KeWaitForSingleObject] works for a Synchronization Event.
+
+ifdef::env-browser[]
+[ditaa,file="Queued-Events/transitions.png"]
+--
+        Non signaled                                    Signaled
++---------------------------+                 +---------------------------+
+| Queued Event              |                 | Queued Event              |
++---------------------------+                 +---------------------------+
+|                           | ---EventSet --> |               +---------+ |
+|   KQUEUE        (empty)   |                 |   KQUEUE      |  DUMMY  | |
+|                           | <--EventWait--- |               +---------+ |
++---------------------------+                 +---------------------------+
+--
+endif::env-browser[]
+ifndef::env-browser[image::Queued-Events/transitions.png[]]
+
+We now have to consider what happens when we have one EventSet concurrently with one or more EventWait's:
+
+1. The EventWait(s) happen before https://msdn.microsoft.com/en-us/library/windows/hardware/ff549591(v=vs.85).aspx[KeReadState]. If the KQUEUE has an item one EventWait gets satisfied, otherwise it blocks. In this case KeReadState will read the KQUEUE's state as 0 and KeInsertQueue will insert the dummy item, which will unblock the EventWait.
+2. The EventWait(s) happen after KeReadState, but before KeInsertQueue. If the dummy item was already in the KQUEUE the KeReadState test will fail and KeInsertQueue will not be executed, but EventWait will be satisfied immediately. If the dummy item was not in the KQUEUE the KeReadState will succeed and EventWait will momentarily block until KeInsertQueue releases it.
+3. The EventWait(s) happen after KeInsertQueue. In this case the dummy item in is the KQUEUE already and one EventWait will be satisfied immediately.
+
+NOTE: _Queued Events_ cannot cleanly support an EventClear operation. The obvious choice of using KeRemoveQueue with a 0 timeout is insufficient because it would associate the current thread with the KQUEUE and that is not desirable. KeRundownQueue cannot be used either because it disassociates all threads from the KQUEUE.
+
+The complete implementation of _Queued Events_ within WinFsp can be found here: https://github.com/billziss-gh/winfsp/blob/v1.1/src/sys/driver.h#L655-L795
+
+== Queued Events Scheduling Characteristics
+
+Queued Events encapsulate KQUEUE's and therefore inherit their scheduling characteristics:
+
+- They have a Last-In First-Out (LIFO) wait discipline.
+- They limit the number of threads that can be satisfied concurrently.
+
+These characteristics are desirable because they reduce the number of context switches thus speeding up the WinFsp IPC implementation. Performance testing immediately after the incorporation of _Queued Events_ into WinFsp showed significant performance improvements; profiling with xperf showed that context switches among file system threads were now a relatively rare event!
+

doc/WinFsp-Service-Architecture.asciidoc

@@ -38,7 +38,7 @@ For example, the MEMFS sample adds the following registry entries in a 64-bit sy
     "Security"="D:P(A;;RPWPLC;;;WD)"
     "JobControl"=dword:00000001
 
-When the WinFsp.Launcher starts up it creates a named pipe that applications can use to start, stop, get information about and list service instances. A small command line utility (`launchctl`) can be used to issue those commands. The CallNamedPipeW API can be used as well.
+When the WinFsp.Launcher starts up it creates a named pipe that applications can use to start, stop, get information about and list service instances. A small command line utility (`launchctl`) can be used to issue those commands. The `CallNamedPipeW` API can be used as well.
 
 One final note regarding security. Notice the `Security` registry value in the example above. This registry value uses SDDL syntax to instruct WinFsp.Launcher to allow Everyone (`WD`) to start (`RP`), stop (`WP`) and get information (`LC`) about the service instance. If the `Security` registry value is missing the default is to allow only LocalSystem and Administrators to control the service instance.
 
@@ -47,3 +47,13 @@ One final note regarding security. Notice the `Security` registry value in the e
 WinFsp includes a Network Provider that integrates with Windows and can be used to start and stop user mode file systems from the Windows shell. To achieve this the Network Provider (implemented as part of the WinFsp DLL) works closely with the WinFsp.Launcher service.
 
 For example, if a user uses the Windows Explorer to map `\\memfs64\share` to the `Z:` drive, the Network Provider will instruct the WinFsp.Launcher to start an instance of the memfs64 service with command line `-i -F NTFS -n 65536 -s 67108864 -u \\memfs64\share -m Z:`. When the user disconnects the `Z:` drive, the Network Provider will instruct the WinFsp.Launcher to stop the previously started instance of the memfs64 service.
+
+== File System Credential Support
+
+Some file systems require credentials in order to allow access and be mounted. Such file systems must add a registry value `Credentials`:
+
+    "Credentials"=dword:00000001
+
+This will instruct the WinFsp Network Provider to request a password from the user prior to starting the file system. This password will then be securely passed to the WinFsp Launcher which in turn will pass it to the user mode file system on its standard input. The user mode file system must respond `OK` if the password is correct and allows access to the user mode file system. Any other response from the user mode file system (including a timeout without a response) is interpreted as an authentication failure.
+
+NOTE: During password entry the user may also choose to "remember" the password in which case it will be saved in the Windows Credential Manager.

src/dll/fuse/fuse.c

@@ -468,17 +468,18 @@ static int fsp_fuse_core_opt_proc(void *opt_data0, const char *arg, int key,
             "    -o gid=N                   set file group (-1 for mounting user group)\n"
             "    -o rellinks                interpret absolute symlinks as volume relative\n"
             "    -o volname=NAME            set volume label\n"
-            "    -o VolumePrefix=UNC        set UNC prefix (\\Server\\Share)\n"
+            "    -o VolumePrefix=UNC        set UNC prefix (/Server/Share)\n"
+            "        --VolumePrefix=UNC     set UNC prefix (\\Server\\Share)\n"
             "    -o FileSystemName=NAME     set file system name\n"
             "    -o DebugLog=FILE           debug log file (requires -d)\n"
             "\n"
             FSP_FUSE_LIBRARY_NAME " advanced options:\n"
             "    -o FileInfoTimeout=N       metadata timeout (millis, -1 for data caching)\n"
-            "    -o SectorSize=N            sector size for Windows (512-4096, deflt: 4096)\n"
-            "    -o SectorsPerAllocationUnit=N  sectors per allocation unit (deflt: 1)\n"
-            "    -o MaxComponentLength=N    max file name component length (deflt: 255)\n"
-            "    -o VolumeCreationTime=T    volume creation time (FILETIME hex format)\n"
-            "    -o VolumeSerialNumber=N    volume serial number (32-bit wide)\n"
+            "    -o SectorSize=N            (512-4096, deflt: 4096)\n"
+            "    -o SectorsPerAllocationUnit=N  (deflt: 1)\n"
+            "    -o MaxComponentLength=N    (deflt: 255)\n"
+            "    -o VolumeCreationTime=T    (FILETIME hex format)\n"
+            "    -o VolumeSerialNumber=N    (32-bit wide)\n"
             );
         opt_data->help = 1;
         return 1;
@@ -513,6 +514,9 @@ static int fsp_fuse_core_opt_proc(void *opt_data0, const char *arg, int key,
             return -1;
         opt_data->VolumeParams.Prefix
             [sizeof opt_data->VolumeParams.Prefix / sizeof(WCHAR) - 1] = L'\0';
+        for (PWSTR P = opt_data->VolumeParams.Prefix; *P; P++)
+            if (L'/' == *P)
+                *P = '\\';
         return 0;
     case 'F':
         if ('f' == arg[0])

src/sys/create.c

@@ -1098,7 +1098,44 @@ static NTSTATUS FspFsvolCreateTryOpen(PIRP Irp, const FSP_FSCTL_TRANSACT_RSP *Re
         return Result;
     }
 
-    FspFileNodeSetFileInfo(FileNode, FileObject, &Response->Rsp.Create.Opened.FileInfo,
+    /*
+     * FspFileNodeTrySetFileInfoOnOpen sets the FileNode's metadata to values reported
+     * by the user mode file system. It does so only if the file is not already open; the
+     * reason is that there is a subtle race condition otherwise.
+     *
+     * Consider that a file is already open and (for example) being appended to. The appends
+     * appear as WRITE IRP's and they are all synchronized by acquiring the FileNode resources
+     * exclusive. Part of the WRITE protocol involves returning an updated FileInfo for the
+     * written FileNode, which the FSD uses to update its view of the file metadata.
+     *
+     * Now consider that a file OPEN comes in. Because the FSD does not know yet which FileNode
+     * will be opened it does not acquire any FileNode. [Note that while it is possible to
+     * uniquely identify a FileNode by FileName currently, this would no longer be the case
+     * when we implement hard links.] The FSD posts the OPEN request to the user mode file system.
+     * The user mode file system processes the OPEN request successfully and responds with the
+     * opened file and its FileInfo.
+     *
+     * Prior to the FSD processing the OPEN response additional WRITE IRP's come through the
+     * original file handle. These WRITE's update the FileSize as understood by the user mode
+     * file system and the corresponding FileInfo gets reported back to the FSD. Eventually the
+     * delayed OPEN response gets processed, which now clobbers the FileInfo as understood by
+     * the FSD.
+     *
+     * The problem here is that OPEN requests have no way of locking the FileNode while the OPEN
+     * request is in transit to the user mode file system. In all other cases the user mode file
+     * system and the FSD update their view of the file's metadata in an atomic fashion. Not so
+     * in the case of OPEN.
+     *
+     * While this is a subtle race condition it can nevertheless creates a real problem. For
+     * example, Explorer often opens files to get information about them and may inappropriately
+     * update the FSD view of the file size during WRITE's.
+     *
+     * FspFileNodeTrySetFileInfoOnOpen attempts to mitigate this problem by only updating the
+     * FileInfo if the file is not already open. This avoids placing stale information in the
+     * FileNode.
+     */
+
+    FspFileNodeTrySetFileInfoOnOpen(FileNode, FileObject, &Response->Rsp.Create.Opened.FileInfo,
         FILE_CREATED == Response->IoStatus.Information);
 
     if (FlushImage)

src/sys/driver.h

@@ -1350,6 +1350,8 @@ VOID FspFileNodeGetFileInfo(FSP_FILE_NODE *FileNode, FSP_FSCTL_FILE_INFO *FileIn
 BOOLEAN FspFileNodeTryGetFileInfo(FSP_FILE_NODE *FileNode, FSP_FSCTL_FILE_INFO *FileInfo);
 VOID FspFileNodeSetFileInfo(FSP_FILE_NODE *FileNode, PFILE_OBJECT CcFileObject,
     const FSP_FSCTL_FILE_INFO *FileInfo, BOOLEAN TruncateOnClose);
+BOOLEAN FspFileNodeTrySetFileInfoOnOpen(FSP_FILE_NODE *FileNode, PFILE_OBJECT CcFileObject,
+    const FSP_FSCTL_FILE_INFO *FileInfo, BOOLEAN TruncateOnClose);
 BOOLEAN FspFileNodeTrySetFileInfo(FSP_FILE_NODE *FileNode, PFILE_OBJECT CcFileObject,
     const FSP_FSCTL_FILE_INFO *FileInfo, ULONG InfoChangeNumber);
 VOID FspFileNodeInvalidateFileInfo(FSP_FILE_NODE *FileNode);

src/sys/file.c

@@ -58,6 +58,8 @@ VOID FspFileNodeGetFileInfo(FSP_FILE_NODE *FileNode, FSP_FSCTL_FILE_INFO *FileIn
 BOOLEAN FspFileNodeTryGetFileInfo(FSP_FILE_NODE *FileNode, FSP_FSCTL_FILE_INFO *FileInfo);
 VOID FspFileNodeSetFileInfo(FSP_FILE_NODE *FileNode, PFILE_OBJECT CcFileObject,
     const FSP_FSCTL_FILE_INFO *FileInfo, BOOLEAN TruncateOnClose);
+BOOLEAN FspFileNodeTrySetFileInfoOnOpen(FSP_FILE_NODE *FileNode, PFILE_OBJECT CcFileObject,
+    const FSP_FSCTL_FILE_INFO *FileInfo, BOOLEAN TruncateOnClose);
 BOOLEAN FspFileNodeTrySetFileInfo(FSP_FILE_NODE *FileNode, PFILE_OBJECT CcFileObject,
     const FSP_FSCTL_FILE_INFO *FileInfo, ULONG InfoChangeNumber);
 VOID FspFileNodeInvalidateFileInfo(FSP_FILE_NODE *FileNode);
@@ -129,6 +131,7 @@ VOID FspFileNodeOplockComplete(PVOID Context, PIRP Irp);
 #pragma alloc_text(PAGE, FspFileNodeGetFileInfo)
 #pragma alloc_text(PAGE, FspFileNodeTryGetFileInfo)
 #pragma alloc_text(PAGE, FspFileNodeSetFileInfo)
+#pragma alloc_text(PAGE, FspFileNodeTrySetFileInfoOnOpen)
 #pragma alloc_text(PAGE, FspFileNodeTrySetFileInfo)
 #pragma alloc_text(PAGE, FspFileNodeInvalidateFileInfo)
 #pragma alloc_text(PAGE, FspFileNodeReferenceSecurity)
@@ -1660,6 +1663,43 @@ VOID FspFileNodeSetFileInfo(FSP_FILE_NODE *FileNode, PFILE_OBJECT CcFileObject,
     }
 }
 
+BOOLEAN FspFileNodeTrySetFileInfoOnOpen(FSP_FILE_NODE *FileNode, PFILE_OBJECT CcFileObject,
+    const FSP_FSCTL_FILE_INFO *FileInfo, BOOLEAN TruncateOnClose)
+{
+    PAGED_CODE();
+
+    BOOLEAN EarlyExit;
+
+    FspFsvolDeviceLockContextTable(FileNode->FsvolDeviceObject);
+    EarlyExit = 1 < FileNode->OpenCount;
+    FspFsvolDeviceUnlockContextTable(FileNode->FsvolDeviceObject);
+
+    if (EarlyExit)
+    {
+        if (TruncateOnClose)
+        {
+            FSP_FSVOL_DEVICE_EXTENSION *FsvolDeviceExtension =
+                FspFsvolDeviceExtension(FileNode->FsvolDeviceObject);
+            UINT64 AllocationSize = FileInfo->AllocationSize > FileInfo->FileSize ?
+                FileInfo->AllocationSize : FileInfo->FileSize;
+            UINT64 AllocationUnit;
+
+            AllocationUnit = FsvolDeviceExtension->VolumeParams.SectorSize *
+                FsvolDeviceExtension->VolumeParams.SectorsPerAllocationUnit;
+            AllocationSize = (AllocationSize + AllocationUnit - 1) / AllocationUnit * AllocationUnit;
+
+            if ((UINT64)FileNode->Header.AllocationSize.QuadPart != AllocationSize ||
+                (UINT64)FileNode->Header.FileSize.QuadPart != FileInfo->FileSize)
+                FileNode->TruncateOnClose = TRUE;
+        }
+
+        return FALSE;
+    }
+
+    FspFileNodeSetFileInfo(FileNode, CcFileObject, FileInfo, TruncateOnClose);
+    return TRUE;
+}
+
 BOOLEAN FspFileNodeTrySetFileInfo(FSP_FILE_NODE *FileNode, PFILE_OBJECT CcFileObject,
     const FSP_FSCTL_FILE_INFO *FileInfo, ULONG InfoChangeNumber)
 {

tools/run-tests.bat

@@ -73,8 +73,6 @@ set opt_tests=^
     ifstest-memfs-dotnet-disk ^
     sample-passthrough-x64 ^
     sample-passthrough-x86 ^
-    sample-passthrough-cpp-x64 ^
-    sample-passthrough-cpp-x86 ^
     sample-passthrough-fuse-x64 ^
     sample-passthrough-fuse-x86 ^
     sample-passthrough-dotnet

tst/memfs/memfs.cpp

@@ -192,7 +192,7 @@ typedef struct _MEMFS_FILE_NODE
     SIZE_T ReparseDataSize;
     PVOID ReparseData;
 #endif
-    ULONG RefCount;
+    volatile LONG RefCount;
 #if defined(MEMFS_NAMED_STREAMS)
     struct _MEMFS_FILE_NODE *MainFileNode;
 #endif
@@ -260,13 +260,13 @@ VOID MemfsFileNodeDelete(MEMFS_FILE_NODE *FileNode)
 static inline
 VOID MemfsFileNodeReference(MEMFS_FILE_NODE *FileNode)
 {
-    FileNode->RefCount++;
+    InterlockedIncrement(&FileNode->RefCount);
 }
 
 static inline
 VOID MemfsFileNodeDereference(MEMFS_FILE_NODE *FileNode)
 {
-    if (0 == --FileNode->RefCount)
+    if (0 == InterlockedDecrement(&FileNode->RefCount))
         MemfsFileNodeDelete(FileNode);
 }
 
@@ -850,14 +850,18 @@ static NTSTATUS Overwrite(FSP_FILE_SYSTEM *FileSystem,
     NTSTATUS Result;
 
 #if defined(MEMFS_NAMED_STREAMS)
-    MEMFS_FILE_NODE_MAP_ENUM_CONTEXT Context = { FALSE };
+    MEMFS_FILE_NODE_MAP_ENUM_CONTEXT Context = { TRUE };
     ULONG Index;
 
     MemfsFileNodeMapEnumerateNamedStreams(Memfs->FileNodeMap, FileNode,
         MemfsFileNodeMapEnumerateFn, &Context);
     for (Index = 0; Context.Count > Index; Index++)
-        if (1 >= Context.FileNodes[Index]->RefCount)
+    {
+        LONG RefCount = Context.FileNodes[Index]->RefCount;
+        MemoryBarrier();
+        if (2 >= RefCount)
             MemfsFileNodeMapRemove(Memfs->FileNodeMap, Context.FileNodes[Index]);
+    }
     MemfsFileNodeMapEnumerateFree(&Context);
 #endif