DeleteFileW and RemoveDirectoryW in recent versions of Windows 10 have
been changed to perform a FileDispositionInformationEx with POSIX
semantics and if that fails to retry with FileDispositionInformation.
Unfortunately this is done even for legitimate error codes such as
STATUS_DIRECTORY_NOT_EMPTY.
This means that user mode file systems have to do unnecessary CanDelete
checks even when they support FileDispositionInformationEx. The extra
check incurs extra context switches, and in some cases it may also be
costly to compute (e.g. FUSE).
We optimize this away by storing the status of the last CanDelete check
in the FileDesc and then continue returning the same status code for
all checks for the same FileDesc.
Turns out that the linker automatically creates .LIB and .EXP files
for all targets that export symbols (e.g. via __declspec(dllexport)).
The FSD now exports symbols for use by other kernel drivers; this
resulted in files like winfsp-x64.lib and winfsp-x64.exp to be
inadvertently created. Unfortunately this clashed with the files with
the same name created from building the DLL.
Since we only want the .LIB and .EXP files produced from the DLL, we
rename the .LIB and .EXP files produced from the FSD to a name that
does not clash. There does not seem to be any way to instruct the
linker to completely turn off .LIB and .EXP file generation for targets
that export symbols.
- 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.
According to the FILE_BASIC_INFORMATION doc a file system should not update a file timestamp when it receives a value of -1 in the corresponding time field.
This commit converts a -1 timestamp to a 0 timestamp; this directs a WinFsp file system not to update the corresponding file timestamp.
This commit fixes issue #362
Some options (VolumePrefix, FileSystemName, volname) have a fixed maximum size.
This commit adds functionality to truncate user-specified long options to their fixed maximum size.
Bill Zissimopoulos
