WinFsp

WinFsp

Frequently Asked Questions

General

  1. I am running Windows 7 and I am finding that the installed driver is not signed.

    Your Windows 7 OS is missing SHA-2 Code Signing Support. Make sure it is fully updated.

  2. I cannot run a program located in a WinFsp drive as administrator. I cannot run regedit.exe from within a WinFsp drive.

    When running an executable as administrator, the Windows OS seems to require that the name of the file system that is housing the executable is "NTFS". For example, the MEMFS file system with the command line memfs-x64.exe -i -F NTFS -m X: works.

  3. Disconnecting (unmapping) a network drive does not work.

    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 article.

  4. Why is the DLL not installed in the Windows system directories?

    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.

    There are a few alternative methods to overcome this problem. WinFsp recommends marking the WinFsp DLL as "delay load" and then using FspLoad to dynamically load the DLL during process initialization. For more information see the WinFsp Tutorial.

  5. Does WinFsp provide debugging symbols?

    Debugging symbols can be found in the https://github.com/winfsp/winfsp.sym repository.

  6. Is there a maximum number of concurrent file systems?

    WinFsp does not have a hard limit of how many file systems can be created or how many processes can create file systems.

    As of the commits required to fix issue #55, there is however a hash table inside the FSD that uses PID’s (Process ID’s) as keys. This hash table currently expects that in general there will not be more than 50 processes creating file systems. However this is not a hard limit.

FUSE

  1. Which version of FUSE does WinFsp-FUSE support?

    It supports both the FUSE 2.8 and FUSE 3.2 API’s. For the FUSE 2.8 API include <fuse/fuse.h>. For the FUSE 3.2 API include <fuse3/fuse.h>.

  2. FUSE on UNIX systems mounts file systems over an existing directory. When mounting a WinFsp-FUSE file system on a directory, the directory is created and later deleted when the file system goes away. What is the reason for this incompatibility?

    It would be preferrable if WinFsp-FUSE behaved like FUSE on UNIX in this instance. However there are a number of reasons that this is not the case.

    When mounting over directories in Windows, WinFsp-FUSE uses a special construct called a reparse point. Reparse points are a general mechanism for adding special behavior to files and directories. One of the possible reparse points is the "mountpoint" reparse point (often called "junction"), which converts a directory into a mount point.

    With this in mind here are the reasons for the current WinFsp-FUSE behavior:

    • Symmetry with mounting on a drive. On Windows drives are created when the file system comes into existence and deleted when it is gone.

    • Inability to mount over a non-empty directory on Windows. On FUSE/UNIX this is possible, but not on Windows because NTFS disallows the creation of (mountpoint) reparse points on non-empty directories.

    • Most importantly: inability to guarantee that the mount point will cease to exist if the file system crashes. WinFsp attempts to guarantee that all resources used by a file system will get cleaned up. This is certainly true for the kernel-mode FSD, but an attempt is made to do so also in user mode. For this reason, drive symbolic links are marked as temporary and (importantly for our discussion) mount directories are opened with FILE_FLAG_DELETE_ON_CLOSE. There is no way to guarantee the removal of a reparse point in the same way.

  3. I have problems getting permissions to work properly in a WinFsp-FUSE file system. Can you help?

    The WinFsp-FUSE layer includes a built-in command line option that can help: -o uid=-1. This instructs the WinFsp-FUSE layer to present all file system files as if they are owned by the user that launched the file system.

    Alternatives include -o uid=-1,gid=-1, which presents files as owned by the user and group that launched the file system and -o uid=-1,gid=11, which presents files as owned by the user that launched the file system and the group "Authenticated Users". (The fsptool utility in the bin subdirectory of the WinFsp installation directory can be used to convert Windows accounts/SID’s to UID’s and vice versa.)