winfsp/doc/Frequently-Asked-Questions.asciidoc

= Frequently Asked Questions

== General

[qanda]

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. You need to install the following security advisory that will rectify the problem:
    https://technet.microsoft.com/en-us/library/security/3033929.aspx


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 http://blogs.interfacett.com/changing-the-network-provider-order-in-windows-10[article].


Case-sensitive file systems do not work properly when mounted as a directory.::

    This is fixed as of WinFsp 2018.2 B3.
+
Windows and WinFsp support case-sensitive file systems. These file systems work properly when mounted as a drive. Unfortunately when a file system is mounted as a directory over NTFS, Windows expects it to be case-insensitive and will UPPERCASE many of the file names sent to the file system.
+
This is an unfortunate but well understood Windows limitation. Case-sensitive file systems should only be mounted as drives.


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.


Does WinFsp provide debugging symbols?::

    Public debugging symbols are already included in the installer. You need to install the "Developer" feature; the symbols can be found in the `sym` directory under the WinFsp installation directory.


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

[qanda]

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


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.


WinFsp-FUSE does not have the ability to support multiple file systems from within the same process. Why?::

    This is supported as of WinFsp 2018.2 B2.
+
The core WinFsp layer always supported multiple file systems in the same process either simultaneously or one after another. However this was not the case with WinFsp-FUSE (i.e. the FUSE layer of WinFsp) prior to version 2018.2 B2. This limitation has been rectified as of WinFsp 2018.2 B2.