mirror of
https://github.com/winfsp/winfsp.git
synced 2025-04-22 16:33:02 -05:00
46 lines
3.2 KiB
Plaintext
46 lines
3.2 KiB
Plaintext
= Frequently Asked Questions
|
|
|
|
== General
|
|
|
|
[qanda]
|
|
|
|
Why is the DLL not installed in the Windows system directories? [@netheril96]::
|
|
|
|
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? [@netheril96]::
|
|
|
|
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? [@efeat]::
|
|
|
|
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?::
|
|
|
|
Currently it supports FUSE 2.8.
|
|
|
|
|
|
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? [@efeat]::
|
|
|
|
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.
|