The HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WinFsp.Launcher\Services registry key maintains all launcher controlled file systems. Unfortunately this key gets removed when uninstalling WinFsp and the WinFsp.Launcher service. If WinFsp is later reinstalled (as in an upgrade) all file system associations are now lost.

The solution here may be to simply use a different registry key for this purpose, one that is not associated with the SCM (Service Control Manager) database.

some usermode fs need two params: "usercontext" and "userconext2 params"
thanks.

Testing on Windows 7 Enterprise (Build 7601, x64).

I am not able to disconnect mapped drives. It claims success, but the mapped drive persists and continues to function. (Using Windows Explorer produces similar results.)

C:\>mkdir y:\foo

C:\>net use y: /delete
y: was deleted successfully.


C:\>dir y:
 Volume in drive Y is MEMFS
 Volume Serial Number is 0DAC-2CB8

 Directory of Y:\

07/29/2016  12:08    <DIR>          .
07/29/2016  12:08    <DIR>          ..
07/29/2016  12:17    <DIR>          foo
               0 File(s)              0 bytes
               3 Dir(s)  17,146,314,752 bytes free

Normal SMB-based mapped drives disconnect normally.

Originally reported by: Bill Zissimopoulos (Bitbucket: billziss, GitHub: billziss-gh)

IRP_MJ_CREATE has some initial support for STATUS_REPARSE, but it has never been tested. Furthermore the WinFsp DLL currently provides no clear means to communicate a STATUS_REPARSE response from the user mode file system.

• Bitbucket: https://bitbucket.org/billziss/winfsp/issue/5

Dear Bill,

I'm using winfsp-1.0.17009.msi.
memfs works nicely when it's mounted on a drive letter but is unstable when it's mounted on a directory.

Steps to reproduce:
1- memfs-x64.exe -m foobar
2- Open foobar with explorer
3- Create a new folder with explorer => OK
4- Create a new folder with explorer => KO
5- Delete the first created folder => KO

Other steps to reproduce:
1- memfs-x64.exe -m foobar
2- Open cmd
3- cd foobar
4- mkdir a => OK
5- cd a => KO (no such directory)

Tested on windows 7 & 8.1 with the same behavior.

Best regards

It would be great if cygwin_conv_path was called if the path is unsupported by winfsp and then a check is done again.

This would be a great compatibility feature as it seems a common thing e.g. for all the python fuse stuff to call sth like: self.fuse_args.mountpoint = os.path.realpath(a.pop()). Otherwise a lot of patching is needed (e.g. in python-fuse or py9p)

I am not sure if it actually makes sense or breaks anything to put that into the cygfuse shim.

The launcher uses GetOverlappedResultEx, which is not available before Windows 8.

Can you provide debugging symbols for the signed release for download?

Just to keep in mind that the driver is rejected in production environnement because it's not signed.

Dear Bill,

WinFsp does not set any security attributes when it's mount on directories.
From my point of view, this is a nice behavior in users directories but not for others (i.e OK in C:\Users\XXX, but not in C:).

In fact security attributes should be a choice of the application which uses WinFsp, don't you think so ?
This also joins issue #37.

WinFsp could have a default behavior and a customizable one with callbacks.

Best Regards

WinFsp is currently GPLv3:

https://github.com/billziss-gh/winfsp/blob/v1.0RC1/License.txt

The license has this header:

The WinFsp project is Copyright (C) Bill Zissimopoulos. It is licensed
under the terms of the GPLv3. The full text of this license follows
below. Commercial licensing options are also available: Please contact
Bill Zissimopoulos <billziss at navimatics.com>.

In order to ease adoption by open-source projects that are not GPLv3, it might be worthwhile to explicitly allow such projects to use and distribute WinFsp without having to comply with the GPLv3 themselves. Closed-source projects would still require a commercial license.

Proposed new header:

The WinFsp project is Copyright (C) Bill Zissimopoulos. It is licensed
under the terms of the GPLv3.

In addition to the terms of the GPLv3, it is explicitly allowed that free
software projects (as per the FSF definition) may use unmodified binary
copies of the software (as released by the WinFsp project) provided that
they include a WinFsp copyright notice in the project's documentation
and/or "About" box, etc.

The full list of free software licenses can be found at the URL below.
https://www.gnu.org/licenses/license-list.html

The licenses that qualify for this exception are listed under "GPL-
Compatible Free Software Licenses" and "GPL-Incompatible Free
Software Licenses.

Unless you have a commercial license you may not: (1) use WinFsp from
a non-free software project/component, and (2) distribute WinFsp with a
non-free software project/component. Please contact Bill Zissimopoulos
<billziss at navimatics.com> for commercial licensing.

I have spent considerable time thinking about the ReadDirectory operation. ReadDirectory is currently defined as:

NTSTATUS (*ReadDirectory)(FSP_FILE_SYSTEM *FileSystem,
    PVOID FileContext, PVOID Buffer, UINT64 Offset, ULONG Length,
    PWSTR Pattern,
    PULONG PBytesTransferred);

ReadDirectory was modelled after fuse_lowlevel_ops::readdir. In particular the Offset parameter allows a file system to return a directory listing in "chunks" ("pages"). The Offset parameter can be used to "seek" into a specific position into the directory stream and start reading from there. The kernel does not interpret the Offset parameter other than to specify that the value 0 means to start from the beginning of the directory stream. The kernel deduces the Offset to send to the user mode file system from the FSP_FSCTL_DIR_INFO::NextOffset fields.

Experience with implementing multiple file systems has shown that ReadDirectory is one of the harder operations to implement because of the Offset parameter. The problem is that many file systems do not have a concept of a numerical offset for directories. One solution seems to use a directory entry's file name as a marker/offset, which must be then somehow converted or mapped to a numerical offset to be returned to the kernel. Another solution is to buffer all directory contents and then use offsets within the buffer as the directory offsets; but this has other problems (among others, it has subtle consistency issues when directories are concurrently modified with multiple directory handles opened).

I have come to the realization that a much better definition for ReadDirectory would be:

NTSTATUS (*ReadDirectory)(FSP_FILE_SYSTEM *FileSystem,
    PVOID FileContext, PVOID Buffer, ULONG Length,
    PWSTR Pattern,
    PWSTR Marker,
    PULONG PBytesTransferred);

Basically the Marker parameter would be NULL or the file name of the last directory entry seen by the kernel. The file system would have to return the first directory entry after the Marker or the first entry if Marker is NULL.

This change assumes that the file system always returns directory entries in the same order for a particular directory. This order does not have to be alphabetical or lexicographical, but it does have to be consistent. It should also be possible/easy for a file system to find all directory entries with file names greater than the Marker in the directory order.

I believe the Marker would simplify returning directory entries for many file systems.

For example, the MEMFS file system already maintains files in alphabetical order and it currently has to maintain a mapping of offsets to file names to implement ReadDirectory. The MEMFS ReadDirectory code would be greatly simplified if a Marker was passed instead.

As another example, in my (currently closed-source) file system SECFS, directory entries are maintained by the order of the cryptographic hash of their filenames. In order to find the directory entry that is greater than the Marker I have to hash it using the crypto-hash and then find all hashes that are greater than the Marker hash.

I am therefore proposing that ReadDirectory be changed to have a Marker instead of an Offset. I am currently experimenting with this change to see if it indeeds makes file system implementation easier. If anyone has strong opinions on this, feel free to voice them.

Originally reported by: Bill Zissimopoulos (Bitbucket: billziss, GitHub: billziss-gh)

The 32-bit version of the WinFsp FSD and DLL has received no testing.

Additionally combinations of 32-bit user mode file systems and DLL calling into the 64-bit FSD should also be tested.

• Bitbucket: https://bitbucket.org/billziss/winfsp/issue/10

Originally reported by: Bill Zissimopoulos (Bitbucket: billziss, GitHub: billziss-gh)

When running the winfsp-tests-x64 test suite on an AppVeyor build worker VM, the test hangs forever. Some investigation using windbg -kl on the VM, reveals that there are no pending IRP's and that the dispatcher threads are blocked waiting for a new IRP to arrive (i.e. normal).

To further investigate this issue:

• In the AppVeyor settings, check the "ignore appveyor.yml" setting so that the AppVeyor UI settings are used.
• Connect to the AppVeyor VM using RDP.
• Let the AppVeyor build complete.
• Open VS2015 and the winfsp.sln project.
• Build Debug/x64 version of WinFsp.
• Execute sc delete and sc create commands to recreate the WinFsp service. Or alternatively use regsvr32 on the WinFsp DLL.
• Launch a live debugging session with windbg -kl.
• Run the lock_noncached_overlapped_test.

• Bitbucket: https://bitbucket.org/billziss/winfsp/issue/12

winfsp has driver and np code, but how to test it? where is the server?

Dear Bill,

I've installed winfsp-1.0.17009.msi on windows 7.
First thanks for that good job !

On that version it's impossible to mount memfs on an absolute path, i.e

• memfs -m Y: => OK
• memfs -m test-winfsp => OK
• memfs -m C:\test-winfsp => KO

I've looked into the winfsp-1.0RC1 source code and found the bug: library.h line 76
L':' == FileName[1] || L'\0' == FileName[2];
should be
L':' == FileName[1] && L'\0' == FileName[2];

In my example, C:\test-winfsp is reconized as a drive letter and winfsp returns an invalid handle error.

Best Regards

FILE_OVERWRITE / FILE_OVERWRITE_IF / FILE_SUPERSEDE currently ignore the passed AllocationSize. This must be corrected. [This requires an API change.]

Additionally NTFS removes all named data streams when overwriting the main file. WinFsp should try to replicate that behavior.

in rename file oper: x:\f001 to x:\f002,
usermode winfsp.dll Request->Req.Create.OpenTargetDirectory always FALSE。

Originally reported by: Bill Zissimopoulos (Bitbucket: billziss, GitHub: billziss-gh)

Internal file locking (MainResource, PagingIoResource) is currently rather crude. In particular the PagingIoResource should only be acquired exclusively when the file size is changed (truncated). In all other cases the PagingIoResource should be acquired shared or not at all.

An important message regarding this subject from Maxim S. Shatskih at the end of this thread: http://www.osronline.com/showthread.cfm?link=275592

• Bitbucket: https://bitbucket.org/billziss/winfsp/issue/7

Topic says it..following the gif on the main page, I get an "Error code: 0x800704b3". Do I need to reboot the windows machine after install? Thanks.

Dear Bill,

It seems that FspFileSystemSetMountPoint & FspFileSystemDelete creates & deletes the mount point when it's a directory.
As fuse does not create and delete the mount directory, don't you think it would be nice to follow that behavior ?

Best Regards

Originally reported by: Bill Zissimopoulos (Bitbucket: billziss, GitHub: billziss-gh)

The FSD is currently test-signed and can not be deployed on a normal Windows installation. The FSD must be properly signed before final release.

• Bitbucket: https://bitbucket.org/billziss/winfsp/issue/8

WinFsp does not currently support the SL_CASE_SENSITIVE flag. This functionality is for POSIX compatibility and is rarely used in practice. NTFS is the primary file system that supports it.

WinFsp supports either case-sensitive or case-insensitive file systems. Windows also allows a mixed sensitivity file system: a case-sensitive file system that "pretends" to be a case-insensitive file system. In such a file system file name lookups are usually case insensitive unless the SL_CASE_SENSITIVE flag is specified.

WinFsp does not support this scenario. The primary reason is that the WinFsp FSD maintains an internal table that maps file names to open files. This table can currently support either case-sensitive lookups or case-insensitive ones, but not mixed sensitivity lookups similar to NTFS.

Would make it easier to install.

The FUSE API readdir only reads the file mode from stat buffer passed to filler. I guess that is why in WinFsp each readdir call is accompanied by many getattr since the NT API returns both name and attributes during directory traversing. This has proved to be a major performance bottleneck in my application, and I would like to see an option to let WinFsp know that the stat buffer I passed to fuse_filler_t is a fully initialized stat structure, so the additional getattr calls will be eliminated.

I ported my fuse system to Windows with WinFsp. However, none of the files in the mounted drive can be opened for writing. New files can be created without problems. The error is always "Access denied". I am sure that my code does not return the error code since I inspect the logs for all the return values.

The getattr calls returns mode in 0666 so that everyone should have read/write/execute access.

Inspecting the security setting reveals the following attributes:

I do not recognize the user name S-1-5-0.

The FSD performs SeCaptureSubjectSecurityContext during the PREPARE phase for SetInformation/Rename and SetSecurity. This appears to be wrong as it captures the security context of the user mode file system and not the originating process! The FSD should instead perform the SeCaptureSubjectSecurityContext during IRP receipt.

I found this bug when testing my application compiled against WinFsp, and it can be reproduced with the bundled passthrough-fuse.

To reproduce it, first create two directories a and b in the mounted filesystem and copy a music file under a. Then open it with some media player and then close it. Try moving the directory a into b and you will get access denied.

My own tracing logs suggest that some files are not closed. Specifically, the open calls are not balanced by release calls. Since it can be reproduced with passthrough-fuse, it must be a problem with WinFsp, either in its core or in its fuse layer.

Dear @billziss-gh,

I've build WinFsp from the sources successfully, but I've notice few minor faults:

• WinFsp must be build from a "git clone" not from the github zip (this may be noticed in the README.md file)
• To build the installer, x86 and x64 solution configuration must be built, then generate installer/CustomActions & installer/winfsp_msi projects
• To enable testsigning the command line is "bcdedit.exe -set testsigning on", not "bcdedit.exe -set testsigning" as it's specified in your documentation http://www.secfs.net/winfsp/develop/debug/

I've build WinFsp on Windows 7 and it's working perfectly on my Windows 8.1 Pro VM.
Do we really need to build it on Windows 10 ?

Best Regards

Originally reported by: Bill Zissimopoulos (Bitbucket: billziss, GitHub: billziss-gh)

FspVolumeDelete is supposed to correctly tear down all data structures related to files housed on a volume that is being deleted. This does not happen currently. The problem exists on both disk and network Fsvol devices (ie. regardless of whether an Fsvrt device exists or not).

It is easy to confirm whether this issue is resolved or not by running !verifier 3 from the WinDbg command line after running winfsp-tests.

• Bitbucket: https://bitbucket.org/billziss/winfsp/issue/2

Testing on Windows 7 Enterprise (Build 7601, x64).

Attempting to copy a large (but not unreasonably large) file to MEMFS produces an error that there is not enough space, though the error dialog shows that there should be enough space.

Originally reported by: Bill Zissimopoulos (Bitbucket: billziss, GitHub: billziss-gh)

It is not clear that WinFsp does the right thing when checking access during delete/rename operations. For example:

• WinFsp does not pay attention to the FILE_DELETE_CHILD access right.
• Delete may succeed even when a file is READ ONLY.
• Rename does not appear to perform any access checks when a file is being replaced.

Investigate the current behavior and ensure that it complies with that of NTFS.

• Bitbucket: https://bitbucket.org/billziss/winfsp/issue/4

Originally reported by: Bill Zissimopoulos (Bitbucket: billziss, GitHub: billziss-gh)

Opportunistic locks are important in network scenarios to improve network traffic and reduce response times. Currently WinFsp does not implement opportunistic locking. This should be rectified.

• Bitbucket: https://bitbucket.org/billziss/winfsp/issue/6

Please add some information (e.g. to README) to understand the technical situation about WinFsp in comparison with Dokany.

E.g. on https://www.reddit.com/r/programming/comments/4tnaoo/winfsp_fuse_for_windows/d5irclf there is something (do not forget about the WinFsp test suite being used also by Dokany) and in the discussion https://groups.google.com/forum/#!msg/dokan/BoLxl5p_fQQ/KwsnjdiiBQAJ there is also plenty of interesting information.

Thanks!

WinFSP 0.14.16197 created drive cannot be shared on Windows 10.0.10586. Steps to reproduce:

Open a CMD window as Administrator, create a memfs as my T: drive:
"\Program Files (x86)\WinFsp\bin\memfs-x64.exe" -s 10485760 -m T:

Open a CMD window as Administrator, create a share to T: so SMB clients can access it
net share MyShare=T:\

Results in error message:
The device or directory does not exist.

More help is available by typing NET HELPMSG 2116.

Trying to create the share as a normal user and you get the ever-so-informative error of "Access Denied"

Please elaborate on the difference and (dis)advantages of the "WinFsp API" which seems redundant, because vast majority (if not all) FUSE filesystems use the "FUSE compatibility layer" API.

In README, there is only the following:

• inc/winfsp: Public headers for the WinFsp API.
• inc/fuse: Public headers for the FUSE compatibility layer.

in rename file oper: x:\f001 to x:\f002,
usermode winfsp.dll Request->Req.Create.OpenTargetDirectory always FALSE。

Not all fuse systems are written with multithreading in mind, and not all work better multithreaded (I/O is inherently a serialized operation). Please support option -s so that a single thread is used.

Originally reported by: Bill Zissimopoulos (Bitbucket: billziss, GitHub: billziss-gh)

A proper WinFsp installer must be created. The installer should install and register the FSD and DLL components as well as supporting files such the public include files, import libraries and any supporting documentation.

• Bitbucket: https://bitbucket.org/billziss/winfsp/issue/9

Originally reported by: Bill Zissimopoulos (Bitbucket: billziss, GitHub: billziss-gh)

FspVolumeDelete is supposed to correctly tear down the Fsvol device and its associated Fsvrt device (if any). Unfortunately it seems that the Fsvrt VPB (which originates as SwapVpb) is not correctly freed. Investigate why this is so and resolve this leak.

It is easy to confirm whether this issue is resolved or not by running !verifier 3 from the WinDbg command line after running winfsp-tests.

• Bitbucket: https://bitbucket.org/billziss/winfsp/issue/1

Sometimes readdir is called without an associated opendir call, so the handle in fuse_info is NULL and that crashed my filesystem. I add a workaround for this, but in the long run, WinFsp should always conform to the official fuse API where reading a directory is issued as opendir then readdir and finally releasedir.

I installed WinFsp and had to copy the dll files to my working directory in order for my fuse executable to find it on load. Why isn't it installed to a system directory?

Currently the only way I know for unmounting is to send CtrL-C to my application, but is there any other way? I cannot simply terminate the process because it may have its own cleanup to do. Best if it can be on a command line so that I can automate some testing tasks.

Would it be possible to build the fuse compatibility API to be loadable without cygwin?

If I've understood what is going on properly between fusepy (via ctypes) <-> 'win fsp fuse compat' <-> winfsp then I think it should be.

Would be great for using fusepy directly (and then being able to use the same code, or something close on *nix).

Originally reported by: Bill Zissimopoulos (Bitbucket: billziss, GitHub: billziss-gh)

Named streams are not currently supported. The main reason for this is that the interactions between a named (sub) stream and the unnamed (main) stream are not yet completely understood, particularly in cases such as stream creation and deletion.

Investigate and understand all issues surrounding stream creation and deletion. Consider use cases such as:

• Open sub-stream and then delete main stream.
• Open sub-stream and then rename main stream.
• Rename file to an existing file that has a sub-stream open.

One potential solution is to always (also) open the main stream when a sub-stream is open. An additional complication to consider is any potential sharing issues.

Stream notifications must also be supported (FILE_ACTION_ADDED_STREAM)

• Bitbucket: https://bitbucket.org/billziss/winfsp/issue/3

WinFsp does not currently support hard links. This should be rectified.

This would involve adding support for FileLinkInformation during IRP_MJ_SET_INFORMATION. The FSP_FILE_SYSTEM_INTERFACE would be updated with an additional CreateLink or Link operation.

Hard link enumeration via FileHardLinkInformation is NTFS specific and should probably not be supported.

[Some of the FSD internals would likely have to be changed as files can no longer be identified uniquely by their file name. This likely means the reintroduction of the "Context" table.]

Originally reported by: Bill Zissimopoulos (Bitbucket: billziss, GitHub: billziss-gh)

A FUSE compatibility layer should exist for WinFsp. Most of the fuse_operations should map relatively easily to an FSP_FSCTL_TRANSACT_REQ/FSP_FSCTL_TRANSACT_RSP transaction. There are some sticky points though:

• The Windows and POSIX security model are very different. Mapping between the two is non-trivial. One potential solution would be to use a mapping model similar to the one in Cygwin. A completely different approach would be to use an extended attribute (e.g. winfsp.Security) to store all security information and do all access checks within WinFsp. This closely resembles the WinFsp native API model.
• The Windows file delete model (open, set disposition flag, cleanup, close) is quite different from the one in POSIX. Any FUSE mapping should be well thought out to ensure that there are no unexpected failure cases.

• Bitbucket: https://bitbucket.org/billziss/winfsp/issue/11

Dear @billziss-gh,

I've noticed that programs have a strange behavior when they are saved on the passthrough FS.

As passthrough is not a part of the RC1 source, I've done the test on the WinFSP master (commit fa652cd), but this behavior can be observed on the RC1 (winfsp-1.0.17009.msi).

I've observed it on Windows 7 SP1 Pro but not on 8.1 Pro.

Steps to reproduce:

• Mount passthrough FS on Y: passthrough-x64.exe -m Y: -p C:\test-winfsp

• Copy a program into Y:

• Run the program from explorer => Error: Invalid parameter
  
  

• Run the program from the command line => Error: The system can't run this program
  

• Run the program from cygwin => Error: bash invalid argument
  

I've tried this with calc.exe and java.exe (1.6.0_45, the first I've found asap).
Of cource these programs work perfectly in C:\test-winfsp and using memfs also.

I was unable to reproduce that on my Windows 8.1 Pro VM because:

• it may work :)
• I've tested only java.exe (calc is not a standalone application in that version of Windows)

Here are the passthrough logs for the calc.exe program only on Win 7:
passthrough-x64.log.zip

Best Regards

Dear @billziss-gh,

WinFsp has goob performances, according to your article https://github.com/billziss-gh/winfsp/wiki/WinFsp-Performance-Testing.

I've made few tests on memfs and passthrough file systems and my conclusions are nearly yours.

I've also made standard actions tests (not only benchmark ones) such as running a program, compiling source codes, unzip archives, fetch/pull data into the file system... They are commons actions that many programs do.

I've also made something similar on Fuse (installed on Debian Jessie).
Here are my conclusions about "commons" actions:

• memfs using Fuse has no impact
• passthrough using Fuse has no impact
• memfs using WinFsp has no impact
• passthrough using WinFsp is twice slower than ntfs

When I say "no impact", it means that these actions run in the same delay on a Fuse or WinFsp FS than on a standard FS (ext4 or ntfs)

First of all, have you ever made such tests and if so, do you confirm my brief conclusion.

Secondly, even if this is a good performance for a user mode FS, do you think that the FastIO support could increase the passthrough performance with WinFsp ? Could it becomes as fast as ntfs ?

Best Regards