This test succeeds on Server 2012 and fails on Server 2016/2019.
Investigation on Server 2019 showed that the FSCTL_SET_REPARSE_POINT
input buffer length was 23 instead of less than
REPARSE_DATA_BUFFER_HEADER_SIZE(==8) like ifstest claims. This
suggests that WinFsp is not the problem here, but perhaps some OS
changes between Server 2012 and Server 2016. NOTE that we are still
using the ifstest from Server 2012 HCK, which may account for the
difference.
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.
