Fuse-like mount point behavior proposal about winfsp HOT 6 CLOSED

Hi, @efeat.

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 ?

In principle I agree with you. I have thought a lot about this and struggled with the decision for some time before settling on the behavior you see.

Before I go on let me briefly explain how mounting over directories is implemented on Windows. Windows uses a special construct called a reparse point for this purpose. 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 some of the reasons that pushed me to make this decision (in no particular order):

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

I have considered the idea of having it both ways: create the mount directory if it does not exist (and then delete it at the end), but also to simply mount the file system on the directory if it does exist (and not delete the directory at the end). The only reason I have not done so, is because I do not have a clean way of removing the reparse point (and keeping the directory) if the file system fails catastrophically (as explained in the bullet point above).

from winfsp.

Hi Bill,

I was expecting a such answer.
I'am agree with points 1 & 2.
So we have to keep in mind this difference between WinFsp and Fuse for cross platforms products.

Thanks

from winfsp.

So we have to keep in mind this difference between WinFsp and Fuse for cross platforms products.

You make a good point though, so I am reopening this to track it and hopefully resolve it some time in the future.

from winfsp.

What about file reparse points? Can we use WinFSP to intercept calls to a specific file, through a mini-filter?

from winfsp.

WinFsp cannot be used to write a mini-filter. It is only meant to write full file systems.

However it is possible to set up a reparse point on NTFS that points into a WinFsp file system. It would have to be one of the reparse points that the system already understands if you want opening the file to work "transparently". So this limits you to "junctions" (which is what WinFsp uses to mount a file system on a directory) and symbolic links (which require administrator privileges currently).

from winfsp.

I am closing this as part of an issue cleanup for the upcoming 1.1 release.

I have spent time thinking on this and believe that while the WinFsp-FUSE behavior defers from that of LIBFUSE/OSXFUSE, the differences are now well understood.

from winfsp.