Public/winfsp
1
0
Fork 0
mirror of https://github.com/winfsp/winfsp.git synced 2025-06-07 12:32:11 -05:00
Code Issues Packages Projects Releases Wiki Activity

doc: update FAQ

Browse Source
This commit is contained in:
Bill Zissimopoulos 2023-02-23 13:50:11 +00:00
parent 1912814d79
commit c04e3d9534
1 changed files with 8 additions and 14 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

22
doc/Frequently-Asked-Questions.asciidoc
View File

@ -6,18 +6,17 @@
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
Your Windows 7 OS is missing SHA-2 Code Signing Support. Make sure it is fully updated.
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.
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.
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 https://www.interfacett.com/blogs/changing-the-network-provider-order-in-windows-10/[article].
Why is the DLL not installed in the Windows system directories?::
@ -29,7 +28,7 @@ There are a few alternative methods to overcome this problem. WinFsp recommends
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.
Debugging symbols can be found in the https://github.com/winfsp/winfsp.sym repository.
Is there a maximum number of concurrent file systems?::
@ -61,11 +60,6 @@ With this in mind here are the reasons for the current WinFsp-FUSE behavior:
- 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.
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.