Although the FSD can now be unloaded, this can only be done safely via
the new FSP_FSCTL_UNLOAD control code. For this reason we disable the
ability to stop the FSD via the Service Manager.
During file system volume creation FspFsctlCreateVolume calls FspFsctlServiceVersion
which examines the version of the driver in use and initializes the variables
FspFsctlTransactCode and FspFsctlTransactBatchCode with either the new
FSP_IOCTL_TRANSACT* codes or the old FSP_FSCTL_TRANSACT* codes.
- FspFileSystemAcquireDirectoryBufferEx takes hint for initial capacity.
- Buffer allocation strategy has been improved to minimize reallocation.
- Quick sort of directory entries now implements median of three partitioning. This improves performance of sorting already sorted data.
- Symlinks: Now supports conventing a directory into a symlink reparse
point.
- Symlinks: The determination of whether a symlink is a file or
directory is now possible for file systems that do not support slashdot
(/.) queries.
- EA: Now allows the removal of non-existant EA without error (this is
allowed on Windows).
When the kernel sends a `Create` message the WinFsp-FUSE layer creates
and opens the file (as per Windows semantics). Sometimes an additional
operation needs to be performed after the file has been opened, which
may fail. In this case the just opened file must be released.
In this particular case the WinFsp-FUSE layer used to call `release`
with an uninitialized path. This commit fixes the problem.
This problem was originally reported in cgofuse (billziss-gh/cgofuse#58)
The original WinFsp protocol for shutting down a file system was to issue
an FSP_FSCTL_STOP control code to the fsctl device. This would set the IOQ
to the "stopped" state and would also cancel all active IRP's. Cancelation
of IRP's would sometimes free buffers that may have still been in use by
the user mode file system threads; hence access violation.
To fix this problem a new control code FSP_FSCTL_STOP0 is introduced. The
new file system shutdown protocol is backwards compatible with the original
one and works as follows:
- First the file system process issues an FSP_FSCTL_STOP0 control code which
sets the IOQ to the "stopped" state but does NOT cancel IRP's.
- Then the file system process waits for its dispatcher threads to complete
(see FspFileSystemStopDispatcher).
- Finally the file system process issues an FSP_FSCTL_STOP control code
which stops the (already stopped) IOQ and cancels all IRP's.
