Windows File System Proxy - FUSE for Windows
OTHER License
Bot releases are visible (Hide)
[FIX] Fixes a rare BSOD on recent versions of Windows. See commit a482183 for details.
[FIX] Fixes a racing issue with two processes competing to start the FSD discovered during testing.
winfsp-2.1.24051.msi
: 1A9C5122C53EE376CDCF9A69F9B0C5D3B297A499105ACC39A50C704F8E80268Ewinfsp-tests-2.1.24051.zip
: 6438C4A7C14AEC2C010EB1EA52C84C4232DD12A9B68763E3EBE6D1134147E903Published by billziss-gh over 1 year ago
This release is a major version change for WinFsp (from 1.x to 2.x). There are no backwards incompatible API changes in this release, but nevertheless enough things change that warrant a version change.
The major new feature of this release is that it allows uninstallation and reinstallation of WinFsp without reboot. Going forward installers named winfsp-2.x.y.msi
can be uninstalled and reinstalled without reboot. Furthermore a later version winfsp-2.x.y.msi
installer can be used to upgrade over an earlier version winfsp-2.x.y.msi
installer. However note that a winfsp-2.x.y.msi
installer cannot be used to upgrade over a legacy winfsp-1.x.y.msi
installer; you will still need to uninstall the old winfsp-1.x.y.msi
installer, potentially reboot and then install the new winfsp-2.x.y.msi
installer.
Changes visible to file system developers are listed below:
WinFsp executable files are now installed by default in the directory C:\Program Files (x86)\WinFsp\SxS\sxs.<InstanceID>\bin
. The previous directory C:\Program Files (x86)\WinFsp\bin
is now a junction that points to the above directory.
The WinFsp driver name is no longer winfsp
, but rather a name such as winfsp+<InstanceID>
. This means that managing the driver using the sc.exe
utility is no longer as easy.
The fsptool
utility has been updated with new commands lsdrv
, load
, unload
and ver
. The lsdrv
, load
and unload
commands can be used to manage the driver from the command line. This is rarely necessary, but may be useful for troubleshooting purposes.
Prior to this release the WinFsp driver would never unmount a file system volume unless the user mode file system requested the unmount. From this release onward it is possible for the WinFsp driver to unmount a file system volume, without a user mode file system request. This is to allow for the driver to be unloaded.
A new operation DispatcherStopped
has been added to FSP_FILE_SYSTEM_INTERFACE
, which is sent after the file system volume has been unmounted and the file system dispatcher has been stopped. This can happen because of a user mode file system request via FspFileSystemStopDispatcher
or because of driver unload. The DispatcherStopped
operation includes a Normally
parameter, which is TRUE
for normal file system shutdown via FspFileSystemStopDispatcher
and FALSE
otherwise.
Native file systems that use the FspService
infrastructure can use the FspFileSystemStopServiceIfNecessary
API to handle the DispatcherStopped
operation (see the MEMFS and NTPTFS samples). FUSE file systems get this functionality for free. .NET file systems that use the Service
class infrastructure also get this functionality for free.
WinFsp now offers a .NET library that targets .NET Framework 3.5 (as before) and one that targets .NET Standard 2.0. This is due to work by @Noire001 in PR #451.
FUSE now supports path components up to 255 characters long (previously it was 255 bytes). This is due to work by @zeho11 in PR #474.
In some rare circumstances WinFsp file systems could report duplicate directory entries. This problem has been fixed. (GitHub issue #475.)
The WinFsp symbols directory has been removed. If you are looking for WinFsp symbols you can find them at https://github.com/winfsp/winfsp.sym
winfsp-2.0.23075.msi
: 6324DC81194A6A08F97B6AECA303CF5C2325C53EDE153BAE9FC4378F0838C101winfsp-tests-2.0.23075.zip
: AEECDAC2BE9684C4FF9D977C41853B0DE9E065C230DBA755E86C3F8130BBC816Published by billziss-gh over 1 year ago
This release is a major version change for WinFsp (from 1.x to 2.x). There are no backwards incompatible API changes in this release, but nevertheless enough things change that warrant a version change.
The major new feature of this release is that it allows uninstallation and reinstallation of WinFsp without reboot. Going forward installers named winfsp-2.x.y.msi
can be uninstalled and reinstalled without reboot. Furthermore a later version winfsp-2.x.y.msi
installer can be used to upgrade over an earlier version winfsp-2.x.y.msi
installer. However note that a winfsp-2.x.y.msi
installer cannot be used to upgrade over a legacy winfsp-1.x.y.msi
installer; you will still need to uninstall the old winfsp-1.x.y.msi
installer, potentially reboot and then install the new winfsp-2.x.y.msi
installer.
Changes visible to file system developers are listed below:
WinFsp executable files are now installed by default in the directory C:\Program Files (x86)\WinFsp\SxS\sxs.<InstanceID>\bin
. The previous directory C:\Program Files (x86)\WinFsp\bin
is now a junction that points to the above directory.
The WinFsp driver name is no longer winfsp
, but rather a name such as winfsp+<InstanceID>
. This means that managing the driver using the sc.exe
utility is no longer as easy.
The fsptool
utility has been updated with new commands lsdrv
, load
, unload
and ver
. The lsdrv
, load
and unload
commands can be used to manage the driver from the command line. This is rarely necessary, but may be useful for troubleshooting purposes.
Prior to this release the WinFsp driver would never unmount a file system volume unless the user mode file system requested the unmount. From this release onward it is possible for the WinFsp driver to unmount a file system volume, without a user mode file system request. This is to allow for the driver to be unloaded.
A new operation DispatcherStopped
has been added to FSP_FILE_SYSTEM_INTERFACE
, which is sent after the file system volume has been unmounted and the file system dispatcher has been stopped. This can happen because of a user mode file system request via FspFileSystemStopDispatcher
or because of driver unload. The DispatcherStopped
operation includes a Normally
parameter, which is TRUE
for normal file system shutdown via FspFileSystemStopDispatcher
and FALSE
otherwise.
Native file systems that use the FspService
infrastructure can use the FspFileSystemStopServiceIfNecessary
API to handle the DispatcherStopped
operation (see the MEMFS and NTPTFS samples). FUSE file systems get this functionality for free. .NET file systems that use the Service
class infrastructure also get this functionality for free.
WinFsp now offers a .NET library that targets .NET Framework 3.5 (as before) and one that targets .NET Standard 2.0. This is due to work by @Noire001 in PR #451.
FUSE now supports path components up to 255 characters long (previously it was 255 bytes). This is due to work by @zeho11 in PR #474.
In some rare circumstances WinFsp file systems could report duplicate directory entries. This problem has been fixed. (GitHub issue #475.)
The WinFsp symbols directory has been removed. If you are looking for WinFsp symbols you can find them at https://github.com/winfsp/winfsp.sym
winfsp-2.0.23055.msi
: 7AB21329F49B4C057FC7C66876D2B502734E37C9BB0AD360DE9E8B3B9170971Fwinfsp-tests-2.0.23055.zip
: 74B39EF9B2BA8D96D69CB99AB786904EB83EB7DB38F245CDAED0E92755A42EBEPublished by billziss-gh over 1 year ago
This release is a major version change for WinFsp (from 1.x to 2.x). There are no backwards incompatible API changes in this release, but nevertheless enough things change that warrant a version change.
The major new feature of this release is that it allows uninstallation and reinstallation of WinFsp without reboot. Going forward installers named winfsp-2.x.y.msi
can be uninstalled and reinstalled without reboot. Furthermore a later version winfsp-2.x.y.msi
installer can be used to upgrade over an earlier version winfsp-2.x.y.msi
installer. However note that a winfsp-2.x.y.msi
installer cannot be used to upgrade over a legacy winfsp-1.x.y.msi
installer; you will still need to uninstall the old winfsp-1.x.y.msi
installer, potentially reboot and then install the new winfsp-2.x.y.msi
installer.
Changes visible to file system developers are listed below:
WinFsp executable files are now installed by default in the directory C:\Program Files (x86)\WinFsp\SxS\sxs.<InstanceID>\bin
. The previous directory C:\Program Files (x86)\WinFsp\bin
is now a junction that points to the above directory.
The WinFsp driver name is no longer winfsp
, but rather a name such as winfsp+<InstanceID>
. This means that managing the driver using the sc.exe
utility is no longer as easy.
The fsptool
utility has been updated with new commands lsdrv
, load
, unload
and ver
. The lsdrv
, load
and unload
commands can be used to manage the driver from the command line. This is rarely necessary, but may be useful for troubleshooting purposes.
Prior to this release the WinFsp driver would never unmount a file system volume unless the user mode file system requested the unmount. From this release onward it is possible for the WinFsp driver to unmount a file system volume, without a user mode file system request. This is to allow for the driver to be unloaded.
A new operation DispatcherStopped
has been added to FSP_FILE_SYSTEM_INTERFACE
, which is sent after the file system volume has been unmounted and the file system dispatcher has been stopped. This can happen because of a user mode file system request via FspFileSystemStopDispatcher
or because of driver unload. The DispatcherStopped
operation includes a Normally
parameter, which is TRUE
for normal file system shutdown via FspFileSystemStopDispatcher
and FALSE
otherwise.
Native file systems that use the FspService
infrastructure can use the FspFileSystemStopServiceIfNecessary
API to handle the DispatcherStopped
operation (see the MEMFS and NTPTFS samples). FUSE file systems get this functionality for free. .NET file systems that use the Service
class infrastructure also get this functionality for free.
WinFsp now offers a .NET library that targets .NET Framework 3.5 (as before) and one that targets .NET Standard 2.0. This is due to work by @Noire001 in PR #451.
FUSE now supports path components up to 255 characters long (previously it was 255 bytes). This is due to work by @zeho11 in PR #474.
The WinFsp symbols directory has been removed. If you are looking for WinFsp symbols you can find them at https://github.com/winfsp/winfsp.sym
winfsp-2.0.23033.msi
: BF3595765FF179B6664600B0065CD77C89823A3803C55CBD35EE4E014141F16Cwinfsp-tests-2.0.23033.zip
: 4A5B1B4F7AC93C91C6A0ADF08DF3CB1BF60AC88DE7EB23470DF89670AAF79BF1Published by billziss-gh almost 2 years ago
Note: This release (2022.2 Update1) is the same as the previous release (2022.2) except that: (1) the kernel-mode drivers are now digitally signed only with the Microsoft Attestation signature, and that: (2) no release assets are digitally signed with SHA-1. (This change was necessary to fix a problem in older versions of Windows such as Windows 7.)
[NEW] WinFsp now supports mounting as directory using the Mount Manager. Use the syntax \\.\C:\Path\To\Mount\Directory
.
[NEW] A new registry setting MountUseMountmgrFromFSD
has been added. See WinFsp Registry Settings for details.
[FIX] A problem with Windows containers has been fixed. (GitHub issue #438.)
[FIX] File systems can now be mounted as directories on ARM64. (GitHub issue #448.)
[FIX] The passthrough file system now reports correct IndexNumber
. (GitHub issue #325.)
[BUILD] Product configuration for the relative paths to the File System Driver, Network Provider and EventLog is now possible via the file build.version.props
located in build\VStudio
.
Published by billziss-gh almost 2 years ago
This release is a major version change for WinFsp (from 1.x to 2.x). There are no backwards incompatible API changes in this release, but nevertheless enough things change that warrant a version change.
The major new feature of this release is that it allows uninstallation and reinstallation of WinFsp without reboot. Going forward installers named winfsp-2.x.y.msi
can be uninstalled and reinstalled without reboot. Furthermore a later version winfsp-2.x.y.msi
installer can be used to upgrade over an earlier version winfsp-2.x.y.msi
installer. However note that a winfsp-2.x.y.msi
installer cannot be used to upgrade over a legacy winfsp-1.x.y.msi
installer; you will still need to uninstall the old winfsp-1.x.y.msi
installer, potentially reboot and then install the new winfsp-2.x.y.msi
installer.
Some changes that may be visible to file system developers are listed below:
WinFsp executable files are now installed by default in the directory C:\Program Files (x86)\WinFsp\SxS\sxs.<InstanceID>\bin
. The previous directory C:\Program Files (x86)\WinFsp\bin
is now a junction that points to the above directory.
The WinFsp driver name is no longer winfsp
, but rather a name such as winfsp+<InstanceID>
. This means that managing the driver using the sc.exe
utility is no longer as easy.
The fsptool
utility has been updated with new commands lsdrv
, load
, unload
and ver
. The lsdrv
, load
and unload
commands can be used to manage the driver from the command line. This is rarely necessary, but may be useful for troubleshooting purposes.
The WinFsp symbols directory has been removed. If you are looking for WinFsp symbols you can find them at https://github.com/winfsp/winfsp.sym
This release introduces significant internal changes, including kernel mode changes to enable the driver to be unloaded. Although there are no known crashes or other problems of such severity, please do not use in production environments.
Published by billziss-gh almost 2 years ago
[NEW] WinFsp now supports mounting as directory using the Mount Manager. Use the syntax \\.\C:\Path\To\Mount\Directory
.
[NEW] A new registry setting MountUseMountmgrFromFSD
has been added. See WinFsp Registry Settings for details.
[FIX] A problem with Windows containers has been fixed. (GitHub issue #438.)
[FIX] File systems can now be mounted as directories on ARM64. (GitHub issue #448.)
[FIX] The passthrough file system now reports correct IndexNumber
. (GitHub issue #325.)
[BUILD] Product configuration for the relative paths to the File System Driver, Network Provider and EventLog is now possible via the file build.version.props
located in build\VStudio
.
Published by billziss-gh about 2 years ago
[NEW] WinFsp now supports mounting as directory using the Mount Manager. Use the syntax \\.\C:\Path\To\Mount\Directory
.
[NEW] A new registry setting MountUseMountmgrFromFSD
has been added. See WinFsp Registry Settings for details.
[FIX] A problem with Windows containers has been fixed. (GitHub issue #438.)
[FIX] File systems can now be mounted as directories on ARM64. (GitHub issue #448.)
[FIX] The passthrough file system now reports correct IndexNumber
. (GitHub issue #325.)
[BUILD] Product configuration for the relative paths to the File System Driver, Network Provider and EventLog is now possible via the file build.version.props
located in build\VStudio
.
Published by billziss-gh about 2 years ago
[NEW] A new registry setting MountUseMountmgrFromFSD
has been added. See WinFsp Registry Settings for details.
[BUILD] Product configuration for the relative paths to the File System Driver, Network Provider and EventLog is now possible via the file build.version.props
located in build\VStudio
.
Published by billziss-gh over 2 years ago
WinFsp has excellent performance according to the latest (June 2022) performance testing. More details here.
[NEW] ARM64 support! For details see WinFsp on ARM64.
[NEW] A new file system operation has been added to the FUSE API:
int (*getpath)(const char *path, char *buf, size_t size,
struct fuse_file_info *fi);
The getpath
operation allows a case-insensitive file system to report the correct case of a file path. For example, getpath
can be used to report that the actual path of a file opened as /PATH/TO/FILE
is really /Path/To/File
. This capability is important for some Windows file system scenarios and can sometimes result in a performance improvement.
[NEW] New ntptfs
sample file system. This is a production quality pass through file system and should be used instead of the original passthrough
file system that was developed for education purposes only.
[NEW] Many performance improvements:
A new PostDispositionForDirOnly
setting has been added to FSP_FSCTL_VOLUME_PARAMS
. This allows a file system to declare that it does not want to see SetInformation/Disposition
requests for files (such requests will still be sent for directories, because a file system is supposed to check if a directory is empty before deletion). This makes file (not directory) deletion faster. This optimization should be safe to enable for most file systems. FUSE file systems get this optimization for free.
The FSD now implements "fast I/O" reads and writes. Fast I/O is a technique for doing I/O without using IRP's (I/O Request Packets) and can only work for file systems using the cache manager (FileInfoTimeout==-1
). This results in significant improvement in read/write scenarios.
The FSD now implements "fast I/O" for "transact" messages. Transact messages are used in the communication protocol between the kernel-mode FSD and the user-mode file system. Fast I/O speeds this communication protocol by as much as 10% in some scenarios. (Fast I/O for transact messages is enabled only when using the new FSP_IOCTL_TRANSACT
control code, but does not require any other special configuration to be enabled.)
The FSD per directory cache limit has been increased from 16K to 64K. This should allow for more directory data to be maintained in kernel and reduce round-trips to the user mode file system.
The user mode directory buffering mechanism (FspFileSystemAcquireDirectoryBuffer
) has been improved. The mechanism uses the quick-sort algorithm internally which can exhibit bad performance when sorting already sorted data. The quick-sort algorithm has been improved with the use use of median of three partitioning, which alleviates this problem.
[NEW] A new registry setting under HKLM\SOFTWARE\WinFsp
(or HKLM\SOFTWARE\WOW6432Node\WinFsp
on a 64-bit system) called MountBroadcastDriveChange
has been introduced, which if set to 1 will broadcast an additional "drive change" message to all top-level windows (including Explorer) during mounting and unmounting.
Normally the Windows infrastructure broadcasts a WM_DEVICECHANGE
message whenever a drive gets added/removed. In some rare systems it is possible for this message to get lost or stalled. The workaround for these rare systems is to enable this registry setting, in which case WinFsp will broadcast the WM_DEVICECHANGE
using a slightly different but more reliable method than the one Windows uses.
For more details see source code comments at FspMountBroadcastDriveChange
.
[FIX] The WinFsp Network Provider now implements NPGetUniversalName
. This fixes problems with some apps (e.g. Photos app).
[FIX] WinFsp-FUSE now supports Azure AD accounts when specifying the -o uid=-1
option. In addition a new option -o uidmap=UID:SID
allows the specification of arbitrary UID<->SID or UID<->UserName mappings.
[FIX] All executables (*.exe,*.dll,*.sys
) in the WinFsp installation bin
folder are now signed.
[FIX] The default value for the registry setting DistinctPermsForSameOwnerGroup
has been changed from 0 to 1.
[BUILD] Product configuration (MyProductName
, etc.) is done by the file build.version.props
located in build\VStudio
. This file was previously named version.properties
.
Published by billziss-gh over 2 years ago
WinFsp 2022+ARM64 has reached "Release Candidate" status. Please install and test this release, especially if you are a file system developer.
WinFsp has excellent performance according to the latest (June 2022) performance testing. More details here.
[NEW] ARM64 support! For details see WinFsp on ARM64.
[NEW] A new file system operation has been added to the FUSE API:
int (*getpath)(const char *path, char *buf, size_t size,
struct fuse_file_info *fi);
The getpath
operation allows a case-insensitive file system to report the correct case of a file path. For example, getpath
can be used to report that the actual path of a file opened as /PATH/TO/FILE
is really /Path/To/File
. This capability is important for some Windows file system scenarios and can sometimes result in a performance improvement.
[NEW] New ntptfs
sample file system. This is a production quality pass through file system and should be used instead of the original passthrough
file system that was developed for education purposes only.
[NEW] Many performance improvements:
A new PostDispositionForDirOnly
setting has been added to FSP_FSCTL_VOLUME_PARAMS
. This allows a file system to declare that it does not want to see SetInformation/Disposition
requests for files (such requests will still be sent for directories, because a file system is supposed to check if a directory is empty before deletion). This makes file (not directory) deletion faster. This optimization should be safe to enable for most file systems. FUSE file systems get this optimization for free.
The FSD now implements "fast I/O" reads and writes. Fast I/O is a technique for doing I/O without using IRP's (I/O Request Packets) and can only work for file systems using the cache manager (FileInfoTimeout==-1
). This results in significant improvement in read/write scenarios.
The FSD now implements "fast I/O" for "transact" messages. Transact messages are used in the communication protocol between the kernel-mode FSD and the user-mode file system. Fast I/O speeds this communication protocol by as much as 10% in some scenarios. (Fast I/O for transact messages is enabled only when using the new FSP_IOCTL_TRANSACT
control code, but does not require any other special configuration to be enabled.)
The FSD per directory cache limit has been increased from 16K to 64K. This should allow for more directory data to be maintained in kernel and reduce round-trips to the user mode file system.
The user mode directory buffering mechanism (FspFileSystemAcquireDirectoryBuffer
) has been improved. The mechanism uses the quick-sort algorithm internally which can exhibit bad performance when sorting already sorted data. The quick-sort algorithm has been improved with the use use of median of three partitioning, which alleviates this problem.
[NEW] A new registry setting under HKLM\SOFTWARE\WinFsp
(or HKLM\SOFTWARE\WOW6432Node\WinFsp
on a 64-bit system) called MountBroadcastDriveChange
has been introduced, which if set to 1 will broadcast an additional "drive change" message to all top-level windows (including Explorer) during mounting and unmounting.
Normally the Windows infrastructure broadcasts a WM_DEVICECHANGE
message whenever a drive gets added/removed. In some rare systems it is possible for this message to get lost or stalled. The workaround for these rare systems is to enable this registry setting, in which case WinFsp will broadcast the WM_DEVICECHANGE
using a slightly different but more reliable method than the one Windows uses.
For more details see source code comments at FspMountBroadcastDriveChange
.
[FIX] The WinFsp Network Provider now implements NPGetUniversalName
. This fixes problems with some apps (e.g. Photos app).
[FIX] WinFsp-FUSE now supports Azure AD accounts when specifying the -o uid=-1
option. In addition a new option -o uidmap=UID:SID
allows the specification of arbitrary UID<->SID or UID<->UserName mappings.
[FIX] All executables (*.exe,*.dll,*.sys
) in the WinFsp installation bin
folder are now signed.
[FIX] The default value for the registry setting DistinctPermsForSameOwnerGroup
has been changed from 0 to 1.
[BUILD] Product configuration (MyProductName
, etc.) is done by the file build.version.props
located in build\VStudio
. This file was previously named version.properties
.
Published by billziss-gh over 2 years ago
This release introduces significant internal changes, including kernel mode changes, to accommodate the ARM64 port. Your testing feedback is greatly appreciated, especially on ARM64 machines.
This release includes private symbols. Use https://github.com/winfsp/winfsp.sym/raw/master/sym
as your symbol path in Visual Studio or WinDbg. More info.
[NEW] ARM64 support! For details see WinFsp on ARM64.
[NEW] A new file system operation has been added to the FUSE API:
int (*getpath)(const char *path, char *buf, size_t size,
struct fuse_file_info *fi);
The getpath
operation allows a case-insensitive file system to report the correct case of a file path. For example, getpath
can be used to report that the actual path of a file opened as /PATH/TO/FILE
is really /Path/To/File
. This capability is important for some Windows file system scenarios and can sometimes result in a performance improvement.
[NEW] New ntptfs
sample file system. This is a production quality pass through file system and should be used instead of the original passthrough
file system that was developed for education purposes only.
[NEW] Many performance improvements:
A new PostDispositionForDirOnly
setting has been added to FSP_FSCTL_VOLUME_PARAMS
. This allows a file system to declare that it does not want to see SetInformation/Disposition
requests for files (such requests will still be sent for directories, because a file system is supposed to check if a directory is empty before deletion). This makes file (not directory) deletion faster. This optimization should be safe to enable for most file systems. FUSE file systems get this optimization for free.
The FSD now implements "fast I/O" reads and writes. Fast I/O is a technique for doing I/O without using IRP's (I/O Request Packets) and can only work for file systems using the cache manager (FileInfoTimeout==-1
). This results in significant improvement in read/write scenarios.
The FSD now implements "fast I/O" for "transact" messages. Transact messages are used in the communication protocol between the kernel-mode FSD and the user-mode file system. Fast I/O speeds this communication protocol by as much as 10% in some scenarios. (Fast I/O for transact messages is enabled only when using the new FSP_IOCTL_TRANSACT
control code, but does not require any other special configuration to be enabled.)
The FSD per directory cache limit has been increased from 16K to 64K. This should allow for more directory data to be maintained in kernel and reduce round-trips to the user mode file system.
The user mode directory buffering mechanism (FspFileSystemAcquireDirectoryBuffer
) has been improved. The mechanism uses the quick-sort algorithm internally which can exhibit bad performance when sorting already sorted data. The quick-sort algorithm has been improved with the use use of median of three partitioning, which alleviates this problem.
[FIX] The WinFsp Network Provider now implements NPGetUniversalName
. This fixes problems with some apps (e.g. Photos app).
[FIX] WinFsp-FUSE now supports Azure AD accounts when specifying the -o uid=-1
option. In addition a new option -o uidmap=UID:SID
allows the specification of arbitrary UID<->SID or UID<->UserName mappings.
[FIX] All executables (*.exe,*.dll,*.sys
) in the WinFsp installation bin
folder are now signed.
[FIX] The default value for the registry setting DistinctPermsForSameOwnerGroup
has been changed from 0 to 1.
[BUILD] Product configuration (MyProductName
, etc.) is done by the file build.version.props
located in build\VStudio
. This file was previously named version.properties
.
Published by billziss-gh over 2 years ago
This release introduces significant internal changes, including kernel mode changes, to accommodate the ARM64 port. Although there are no known crashes or other problems of such severity, please do not use in production environments.
Your testing feedback is greatly appreciated, especially on ARM64 machines.
This release includes private symbols. Use https://github.com/winfsp/winfsp.sym/raw/master/sym
as your symbol path in Visual Studio or WinDbg. More info.
[NEW] ARM64 support! For details see WinFsp on ARM64.
[NEW] A new file system operation has been added to the FUSE API:
int (*getpath)(const char *path, char *buf, size_t size,
struct fuse_file_info *fi);
The getpath
operation allows a case-insensitive file system to report the correct case of a file path. For example, getpath
can be used to report that the actual path of a file opened as /PATH/TO/FILE
is really /Path/To/File
. This capability is important for some Windows file system scenarios and can sometimes result in a performance improvement.
[NEW] Many performance improvements:
A new PostDispositionForDirOnly
setting has been added to FSP_FSCTL_VOLUME_PARAMS
. This allows a file system to declare that it does not want to see SetInformation/Disposition
requests for files (such requests will still be sent for directories, because a file system is supposed to check if a directory is empty before deletion). This makes file (not directory) deletion faster. This optimization should be safe to enable for most file systems. FUSE file systems get this optimization for free.
The FSD now implements "fast I/O" reads and writes. Fast I/O is a technique for doing I/O without using IRP's (I/O Request Packets) and can only work for file systems using the cache manager (FileInfoTimeout==-1
). This results in significant improvement in read/write scenarios.
The FSD per directory cache limit has been increased from 16K to 64K. This should allow for more directory data to be maintained in kernel and reduce round-trips to a user mode file system.
The user mode directory buffering mechanism (FspFileSystemAcquireDirectoryBuffer
) has been improved. The mechanism uses the quick-sort algorithm internally which can exhibit bad performance when sorting already sorted data. The quick-sort algorithm has been improved with the use use of median of three partitioning, which alleviates this problem.
[NEW] The default value for the registry setting DistinctPermsForSameOwnerGroup
has been changed from 0 to 1.
[NEW] New ntptfs
sample file system. This is a production quality pass through file system and should be used instead of the original passthrough
file system that was developed for education purposes only.
[FIX] The WinFsp Network Provider now implements NPGetUniversalName
. This fixes problems with some apps (e.g. Photos app).
[BUILD] Product configuration (MyProductName
, etc.) is done by the file build.version.props
located in build\VStudio
. This file was previously named version.properties
.
Published by billziss-gh over 2 years ago
This release introduces significant internal changes, including kernel mode changes, to accommodate the ARM64 port. Although there are no known crashes or other problems of such severity, please do not use in production environments.
Your testing feedback is greatly appreciated, especially on ARM64 machines.
This release includes private symbols. Use https://github.com/billziss-gh/winfsp.sym/raw/master/sym
as your symbol path in Visual Studio or WinDbg. More info.
[NEW] ARM64 support! For details see WinFsp on ARM64.
[NEW] New ntptfs
sample file system. This is a production quality pass through file system and should be used instead of the original passthrough
file system that was developed for education purposes only.
[NEW] The default value for the registry setting DistinctPermsForSameOwnerGroup
has been changed from 0 to 1.
[BUILD] Product configuration (MyProductName
, etc.) is done by the file build.version.props
located in build\VStudio
. This file was previously named version.properties
.
Published by billziss-gh almost 3 years ago
This release includes private symbols. Use https://github.com/billziss-gh/winfsp.sym/raw/master/sym
as your symbol path in Visual Studio or WinDbg. More info.
[NEW] Official Windows 11 support.
[NEW] Support for FileDispositionInformationEx
and FileRenameInformationEx
has been added. Native and .NET file systems must enable this support by setting SupportsPosixUnlinkRename
in FSP_FSCTL_VOLUME_PARAMS
. FUSE file systems have this support enabled by default, but they can disable it by using the -o LegacyUnlinkRename
command line option.
[NEW] WinFsp now supports rebranding of the build products. This is primarily useful to commercial licensees. See https://github.com/billziss-gh/winfsp/wiki/WinFsp-Rebranding for more information.
[NEW] WinFsp-FUSE has a new capability FSP_FUSE_CAP_DELETE_ACCESS
. If this capability is specified WinFsp will call the FUSE access
method with the WinFsp-specific flag FSP_FUSE_DELETE_OK
to check whether the deletion should be allowed. This can be used to disallow deletion of files and directories that would normally be allowed under the FUSE/POSIX model.
[NEW] WinFsp-FUSE has a new method for determining file access in the case where the user's primary SID (Windows Security Identifier) and group SID are the same (for example, this can happen when someone uses a Microsoft account as their primary login).
Previously when the user SID and group SID were the same WinFsp-FUSE looked at the UNIX permissions for the owner and the UNIX permissions for the group and used the MOST restrictive permissions, which often resulted in inadvertent "access denied" errors. (For example, if the owner permission was rw-
and the group permission was ---
the result was ---
and therefore access denied).
Going forward this behavior will change. The user and group mode permissions will not be considered together even in the case where the user SID and group SID are the same. This will resolve the access denied errors.
However to preserve backward compatibility (there might be some file systems that rely on the old behavior) we will do so in stages. For release v1.10 (2022) there is a new registry setting under HKLM\SOFTWARE\WinFsp
(or HKLM\SOFTWARE\WOW6432Node\WinFsp
on a 64-bit system) called DistinctPermsForSameOwnerGroup
, which if set to 1 will direct WinFsp-FUSE to use the new behavior. The default value is 0 which directs WinFsp-FUSE to use the old behavior. This default will change in a future release.
[NEW] A new registry setting under HKLM\SOFTWARE\WinFsp
(or HKLM\SOFTWARE\WOW6432Node\WinFsp
on a 64-bit system) called MountDoNotUseLauncher
has been introduced, which if set to 1 will disable the use of the Launcher during mounting. The default value is 0 which allows the use of the Launcher during mounting in those rare cases when necessary. (In general the Launcher is not necessary for mounting. However when running a file system in the Windows Service context (session 0) under an account that is not LocalSystem (e.g. NT AUTHORITY\NETWORK SERVICE
), the Launcher is used to create global drives.)
[NEW] A new sample memfs-fuse file system written in C++ has been added. This file system uses all FUSE2 features offered by WinFsp-FUSE, passes all file system tests (that can be passed by a FUSE2 file system) and will act as the reference WinFsp-FUSE file system going forward.
[FIX] Fixed a problem with FspFileSystemReadDirectoryBuffer
and file systems that support pattern matching (like passthrough). (GitHub issue #351.)
[FIX] File share access when overwriting a file (e.g. when using TRUNCATE_EXISTING
) is now done in a manner compatible with NTFS (previously there were cases when overwriting a file where behavior diverged from the NTFS one). (See GitHub issue #364.)
[FIX] The FSD will now report a file's reparse tag in the EaSize
field of FILE_FULL_DIR_INFORMATION
and friends. This fixes problems such as cmd.exe
not recognizing symlinks in a dir
command. (See GitHub issue #380.)
[FIX] Fixed a problem in the file system shutdown protocol which resolves an occasional access violation in the user mode file system process. Previously it was possible for a file system to crash when stopping itself using FspFileSystemStopDispatcher
; this problem has been rectified. (See GitHub issue #369.)
[FIX] Improved symlink support for FUSE file systems. Notably:
FUSE file systems now support converting a directory to a symlink reparse point.
The determination of whether a symlink is a file or directory (necessary because the Windows file system makes this distinction) is now possible for file systems that do not support slashdot (/.
) queries. (A slashdot query is one like getattr("/PATH/.")
; such queries are not normally expected to be resolved by FUSE file systems.)
[FIX] Fixed a problem in the FUSE layer where in some rare circumstances the release
operation could be called with an uninitialized path
argument. (See GitHub issue billziss-gh/cgofuse#58 and commit f51bdef53427d1bba688fb6c768792fdc22ffc7b).
[FIX] Fixed a potential problem when launching file system instances using the Launcher. (See GitHub issue #356.)
[FIX] The winfsp.h
header no longer defines FILE_FULL_EA_INFORMATION
when compiled under mingw. This is because the mingw tool chain already includes a definition of this type. (GitHub PR #371. Thanks @ lemourin.)
Published by billziss-gh almost 3 years ago
This release includes private symbols. Use https://github.com/billziss-gh/winfsp.sym/raw/master/sym
as your symbol path in Visual Studio or WinDbg. More info.
[NEW] Official Windows 11 support.
[NEW] Support for FileDispositionInformationEx
and FileRenameInformationEx
has been added. Native and .NET file systems must enable this support by setting SupportsPosixUnlinkRename
in FSP_FSCTL_VOLUME_PARAMS
. FUSE file systems have this support enabled by default, but they can disable it by using the -o LegacyUnlinkRename
command line option.
[NEW] WinFsp now supports rebranding of the build products. This is primarily useful to commercial licensees. See https://github.com/billziss-gh/winfsp/wiki/WinFsp-Rebranding for more information.
[NEW] WinFsp-FUSE has a new capability FSP_FUSE_CAP_DELETE_ACCESS
. If this capability is specified WinFsp will call the FUSE access
method with the WinFsp-specific flag FSP_FUSE_DELETE_OK
to check whether the deletion should be allowed. This can be used to disallow deletion of files and directories that would normally be allowed under the FUSE/POSIX model.
[NEW] WinFsp-FUSE has a new method for determining file access in the case where the user's primary SID (Windows Security Identifier) and group SID are the same (for example, this can happen when someone uses a Microsoft account as their primary login).
Previously when the user SID and group SID were the same WinFsp-FUSE looked at the UNIX permissions for the owner and the UNIX permissions for the group and used the MOST restrictive permissions, which often resulted in inadvertent "access denied" errors. (For example, if the owner permission was rw-
and the group permission was ---
the result was ---
and therefore access denied).
Going forward this behavior will change. The user and group mode permissions will not be considered together even in the case where the user SID and group SID are the same. This will resolve the access denied errors.
However to preserve backward compatibility (there might be some file systems that rely on the old behavior) we will do so in stages. For release v1.10 (2022) there is a new registry setting under HKLM\SOFTWARE\WinFsp
(or HKLM\SOFTWARE\WOW6432Node\WinFsp
on a 64-bit system) called DistinctPermsForSameOwnerGroup
, which if set to 1 will direct WinFsp-FUSE to use the new behavior. The default value is 0 which directs WinFsp-FUSE to use the old behavior. This default will change in a future release.
[NEW] A new registry setting under HKLM\SOFTWARE\WinFsp
(or HKLM\SOFTWARE\WOW6432Node\WinFsp
on a 64-bit system) called MountDoNotUseLauncher
has been introduced, which if set to 1 will disable the use of the Launcher during mounting. The default value is 0 which allows the use of the Launcher during mounting in those rare cases when necessary. (In general the Launcher is not necessary for mounting. However when running a file system in the Windows Service context (session 0) under an account that is not LocalSystem (e.g. NT AUTHORITY\NETWORK SERVICE
), the Launcher is used to create global drives.)
[FIX] Fixed a problem with FspFileSystemReadDirectoryBuffer
and file systems that support pattern matching (like passthrough). (GitHub issue #351.)
[FIX] File share access when overwriting a file (e.g. when using TRUNCATE_EXISTING
) is now done in a manner compatible with NTFS (previously there were cases when overwriting a file where behavior diverged from the NTFS one). (See GitHub issue #364.)
[FIX] The FSD will now report a file's reparse tag in the EaSize
field of FILE_FULL_DIR_INFORMATION
and friends. This fixes problems such as cmd.exe
not recognizing symlinks in a dir
command. (See GitHub issue #380.)
[FIX] Fixed a problem in the file system shutdown protocol which resolves an occasional access violation in the user mode file system process. Previously it was possible for a file system to crash when stopping itself using FspFileSystemStopDispatcher
; this problem has been rectified. (See GitHub issue #369.)
[FIX] Fixed a problem in the FUSE layer where in some rare circumstances the release
operation could be called with an uninitialized path
argument. (See GitHub issue billziss-gh/cgofuse#58 and commit f51bdef53427d1bba688fb6c768792fdc22ffc7b).
[FIX] Fixed a potential problem when launching file system instances using the Launcher. (See GitHub issue #356.)
[FIX] The winfsp.h
header no longer defines FILE_FULL_EA_INFORMATION
when compiled under mingw. This is because the mingw tool chain already includes a definition of this type. (GitHub PR #371. Thanks @ lemourin.)
Published by billziss-gh almost 3 years ago
The Beta has been renamed to WinFsp 2022 Beta4.
The Delete functionality introduced in release 2021.1 Beta3 (v1.10B3) has been reverted. For more information see this thread: https://groups.google.com/g/winfsp/c/1VYgTp1JpSI
This release includes private symbols. Use https://github.com/billziss-gh/winfsp.sym/raw/master/sym
as your symbol path in Visual Studio or WinDbg. More info.
[NEW] Official Windows 11 support.
[NEW] Support for FileDispositionInformationEx
and FileRenameInformationEx
has been added.
[NEW] WinFsp now supports rebranding of the build products. This is primarily useful to commercial licensees. See https://github.com/billziss-gh/winfsp/wiki/WinFsp-Rebranding for more information.
[NEW] WinFsp-FUSE has a new capability FSP_FUSE_CAP_DELETE_ACCESS
. If this capability is specified WinFsp will call the FUSE access
method with the WinFsp-specific flag FSP_FUSE_DELETE_OK
to check whether the deletion should be allowed. This can be used to disallow deletion of files and directories that would normally be allowed under the FUSE/POSIX model.
[NEW] WinFsp-FUSE has a new method for determining file access in the case where the user's primary SID (Windows Security Identifier) and group SID are the same (for example, this can happen when someone uses a Microsoft account as their primary login).
Previously when the user SID and group SID were the same WinFsp-FUSE looked at the UNIX permissions for the owner and the UNIX permissions for the group and used the MOST restrictive permissions, which often resulted in inadvertent "access denied" errors. (For example, if the owner permission was rw-
and the group permission was ---
the result was ---
and therefore access denied).
Going forward this behavior will change. The user and group mode permissions will not be considered together even in the case where the user SID and group SID are the same. This will resolve the access denied errors.
However to preserve backward compatibility (there might be some file systems that rely on the old behavior) we will do so in stages. For release v1.10 (2022) there is a new registry setting under HKLM\SOFTWARE\WinFsp
(or HKLM\SOFTWARE\WOW6432Node\WinFsp
on a 64-bit system) called DistinctPermsForSameOwnerGroup
, which if set to 1 will direct WinFsp-FUSE to use the new behavior. The default value is 0 which directs WinFsp-FUSE to use the old behavior. This default will change in a future release.
[NEW] A new registry setting under HKLM\SOFTWARE\WinFsp
(or HKLM\SOFTWARE\WOW6432Node\WinFsp
on a 64-bit system) called MountDoNotUseLauncher
has been introduced, which if set to 1 will disable the use of the Launcher during mounting. The default value is 0 which allows the use of the Launcher during mounting in those rare cases when necessary. (In general the Launcher is not necessary for mounting. However when running a file system in the Windows Service context (session 0) under an account that is not LocalSystem (e.g. NT AUTHORITY\NETWORK SERVICE
), the Launcher is used to create global drives.)
[FIX] File share access when overwriting a file (e.g. when using TRUNCATE_EXISTING
) is now done in a manner compatible with NTFS (previously there were cases when overwriting a file where behavior diverged from the NTFS one). (See GitHub issue #364.)
[FIX] The FSD will now report a file's reparse tag in the EaSize
field of FILE_FULL_DIR_INFORMATION
and friends. This fixes problems such as cmd.exe
not recognizing symlinks in a dir
command. (See GitHub issue #380.)
[FIX] Fixed a problem in the file system shutdown protocol which resolves an occasional access violation in the user mode file system process. Previously it was possible for a file system to crash when stopping itself using FspFileSystemStopDispatcher
; this problem has been rectified. (See GitHub issue #369.)
[FIX] Fixed a problem in the FUSE layer where in some rare circumstances the release
operation could be called with an uninitialized path
argument. (See GitHub issue billziss-gh/cgofuse#58 and commit f51bdef53427d1bba688fb6c768792fdc22ffc7b).
[FIX] Fixed a potential problem when launching file system instances using the Launcher. (See GitHub issue #356.)
[FIX] The winfsp.h
header no longer defines FILE_FULL_EA_INFORMATION
when compiled under mingw. This is because the mingw tool chain already includes a definition of this type. (GitHub PR #371. Thanks @ lemourin.)
Published by billziss-gh almost 3 years ago
[NEW] Official Windows 11 support.
[NEW] WinFsp has had its Delete functionality redesigned in release 2021.1 Beta3. This redesign unifies all Windows file deletion semantics under a single file system operation that also supports the new POSIX semantics introduced in Windows 10 Redstone 1. The new Delete design is recommended for new file systems, however existing file systems will continue to work without any changes. See https://github.com/billziss-gh/winfsp/wiki/WinFsp-Delete-Redesign for more information. PLEASE NOTE: I have discovered a problem with the current implementation of POSIX unlink in this Beta of WinFsp, which unfortunately may invalidate the new Delete design. Please hold off on adopting this design for now.
[NEW] Support for FileDispositionInformationEx
and FileRenameInformationEx
has been added (see above).
[NEW] WinFsp now supports rebranding of the build products. This is primarily useful to commercial licensees. See https://github.com/billziss-gh/winfsp/wiki/WinFsp-Rebranding for more information.
[NEW] WinFsp-FUSE has a new capability FSP_FUSE_CAP_DELETE_ACCESS
. If this capability is specified WinFsp will call the FUSE access
method with the WinFsp-specific flag FSP_FUSE_DELETE_OK
to check whether the deletion should be allowed. This can be used to disallow deletion of files and directories that would normally be allowed under the FUSE/POSIX model.
[NEW] WinFsp-FUSE has a new method for determining file access in the case where the user's primary SID (Windows Security Identifier) and group SID are the same (for example, this can happen when someone uses a Microsoft account as their primary login).
Previously when the user SID and group SID were the same WinFsp-FUSE looked at the UNIX permissions for the owner and the UNIX permissions for the group and used the MOST restrictive permissions, which often resulted in inadvertent "access denied" errors. (For example, if the owner permission was rw-
and the group permission was ---
the result was ---
and therefore access denied).
Going forward this behavior will change. The user and group mode permissions will not be considered together even in the case where the user SID and group SID are the same. This will resolve the access denied errors.
However to preserve backward compatibility (there might be some file systems that rely on the old behavior) we will do so in stages. For release v1.10 (2021.1) there is a new registry setting under HKLM\SOFTWARE\WinFsp
(or HKLM\SOFTWARE\WOW6432Node\WinFsp
on a 64-bit system) called DistinctPermsForSameOwnerGroup
, which if set to 1 will direct WinFsp-FUSE to use the new behavior. The default value is 0 which directs WinFsp-FUSE to use the old behavior. This default will change in a future release.
[NEW] A new registry setting under HKLM\SOFTWARE\WinFsp
(or HKLM\SOFTWARE\WOW6432Node\WinFsp
on a 64-bit system) called MountDoNotUseLauncher
has been introduced, which if set to 1 will disable the use of the Launcher during mounting. The default value is 0 which allows the use of the Launcher during mounting in those rare cases when necessary. (In general the Launcher is not necessary for mounting. However when running a file system in the Windows Service context (session 0) under an account that is not LocalSystem (e.g. NT AUTHORITY\NETWORK SERVICE
), the Launcher is used to create global drives.)
[FIX] File share access when overwriting a file (e.g. when using TRUNCATE_EXISTING
) is now done in a manner compatible with NTFS (previously there were cases when overwriting a file where behavior diverged from the NTFS one). (See GitHub issue #364.)
[FIX] The FSD will now report a file's reparse tag in the EaSize
field of FILE_FULL_DIR_INFORMATION
and friends. This fixes problems such as cmd.exe
not recognizing symlinks in a dir
command. (See GitHub issue #380.)
[FIX] Fixed a problem in the file system shutdown protocol which resolves an occasional access violation in the user mode file system process. Previously it was possible for a file system to crash when stopping itself using FspFileSystemStopDispatcher
; this problem has been rectified. (See GitHub issue #369.)
[FIX] Fixed a problem in the FUSE layer where in some rare circumstances the release
operation could be called with an uninitialized path
argument. (See GitHub issue billziss-gh/cgofuse#58 and commit f51bdef53427d1bba688fb6c768792fdc22ffc7b).
[FIX] Fixed a potential problem when launching file system instances using the Launcher. (See GitHub issue #356.)
[FIX] The winfsp.h
header no longer defines FILE_FULL_EA_INFORMATION
when compiled under mingw. This is because the mingw tool chain already includes a definition of this type. (GitHub PR #371. Thanks @ lemourin.)
Published by billziss-gh over 3 years ago
[NEW] WinFsp now supports rebranding of the build products. This is primarily useful to commercial licensees. See https://github.com/billziss-gh/winfsp/wiki/WinFsp-Rebranding for more information.
[NEW] WinFsp-FUSE has a new method for determining file access in the case where the user's primary SID (Windows Security Identifier) and group SID are the same (for example, this can happen when someone uses a Microsoft account as their primary login).
Previously when the user SID and group SID were the same WinFsp-FUSE looked at the UNIX permissions for the owner and the UNIX permissions for the group and used the MOST restrictive permissions, which often resulted in inadvertent "access denied" errors. (For example, if the owner permission was rw-
and the group permission was ---
the result was ---
and therefore access denied).
Going forward this behavior will change. The user and group mode permissions will not be considered together even in the case where the user SID and group SID are the same. This will resolve the access denied errors.
However to preserve backward compatibility (there might be some file systems that rely on the old behavior) we will do so in stages. For release v1.10 (2021.1) there is a new registry setting under HKLM\SOFTWARE\WinFsp
(or HKLM\SOFTWARE\WOW6432Node\WinFsp
on a 64-bit system) called DistinctPermsForSameOwnerGroup
, which if set to 1 will direct WinFsp-FUSE to use the new behavior. The default value is 0 which directs WinFsp-FUSE to use the old behavior. This default will change in a future release.
[FIX] File share access when overwriting a file (e.g. when using TRUNCATE_EXISTING
) is now done in a manner compatible with NTFS (previously there were cases when overwriting a file where behavior diverged from the NTFS one). (See GitHub issue #364.)
[FIX] Fixed a problem in the file system shutdown protocol which resolves an occasional access violation in the user mode file system process. Previously it was possible for a file system to crash when stopping itself using FspFileSystemStopDispatcher
; this problem has been rectified. (See GitHub issue #369.)
[FIX] Fixed a problem in the FUSE layer where in some rare circumstances the release
operation could be called with an uninitialized path
argument. (See GitHub issue billziss-gh/cgofuse#58 and commit f51bdef53427d1bba688fb6c768792fdc22ffc7b).
[FIX] The winfsp.h
header no longer defines FILE_FULL_EA_INFORMATION
when compiled under mingw. This is because the mingw tool chain already includes a definition of this type. (GitHub PR #371. Thanks @lemourin.)
Published by billziss-gh over 3 years ago
[NEW] WinFsp now supports rebranding of the build products. This is primarily useful to commercial licensees. See https://github.com/billziss-gh/winfsp/wiki/WinFsp-Rebranding for more information.
[NEW] WinFsp-FUSE has a new method for determining file access in the case where the user's primary SID (Windows Security Identifier) and group SID are the same (for example, this can happen when someone uses a Microsoft account as their primary login).
Previously when the user SID and group SID were the same WinFsp-FUSE looked at the UNIX permissions for the owner and the UNIX permissions for the group and used the MOST restrictive permissions, which often resulted in inadvertent "access denied" errors. (For example, if the owner permission was rw-
and the group permission was ---
the result was ---
and therefore access denied).
Going forward this behavior will change. The user and group mode permissions will not be considered together even in the case where the user SID and group SID are the same. This will resolve the access denied errors.
However to preserve backward compatibility (there might be some file systems that rely on the old behavior) we will do so in stages. For release v1.10 (2021.1) there is a new registry setting under HKLM\SOFTWARE\WinFsp
(or HKLM\SOFTWARE\WOW6432Node\WinFsp
on a 64-bit system) called DistinctPermsForSameOwnerGroup
, which if set to 1 will direct WinFsp-FUSE to use the new behavior. The default value is 0 which directs WinFsp-FUSE to use the old behavior. This default will change in a future release.
[FIX] File share access when overwriting a file (e.g. when using TRUNCATE_EXISTING
) is now done in a manner compatible with NTFS (previously there were cases when overwriting a file where behavior diverged from the NTFS one). (See GitHub issue #364.)
[FIX] Fixed a problem in the file system shutdown protocol which resolves an occasional access violation in the user mode file system process. Previously it was possible for a file system to crash when stopping itself using FspFileSystemStopDispatcher
; this problem has been rectified. (See GitHub issue #369.)
[FIX] The winfsp.h
header no longer defines FILE_FULL_EA_INFORMATION
when compiled under mingw. This is because the mingw tool chain already includes a definition of this type. (GitHub PR #371. Thanks @lemourin.)