How to mount as network drive in FUSE API
Siyuan Ren
Bill Zissimopoulos
WinFsp supports network drives and so does the WinFsp-FUSE layer.
Suppose that you want to create a network drive with UNC path \\myfilesystem\myserver. You would then pass the following command line options to the fuse_main or fuse_new API's:
Either as a double dash option (--):
--VolumePrefix=\myfilesystem\myserver
(Use backslashes and SINGLE backslash before myfilesystem.)
Or as a FUSE option (-o):
-oVolumePrefix=/myfilesystem/myserver
(Use slashes and SINGLE slash before myfilesystem.)
Thanks.
Bill
--
You received this message because you are subscribed to the Google Groups "WinFsp" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
winfsp+un...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/winfsp/12b9210a-31e1-4e53-a8ec-2b33c3779aben%40googlegroups.com.
Siyuan Ren
Bill Zissimopoulos
Windows has a few different namespaces.
- There is the NTOS namespace (often called the Object Manager namespace) where all Windows objects live.
- This is the primary Windows namespace and all other namespaces are translated to this one.
- There are the Win32 drive namespaces (instead of a single file tree as in UNIX, you have a forest of trees A:, B:, C:, etc.)
- A Win32 path X:\path\to\file may correspond to the NTOS path \Device\VolumeXYZ\path\to\file.
- There is the UNC (Universal Naming Convention) namespace, which in general looks like \\server\share\path\to\file
- A UNC path \\server\share\path\to\file corresponds to the NTOS path \Device\Mup\server\share\path\to\file.
When a file is opened Windows first translates the Win32 path to the equivalent NTOS path. Then it attempts to open the NTOS path and notes that the path names a "device" (e.g. \Device\VolumeXYZ or \Device\Mup). At this point it sends a special OPEN message to the device with the remaining path (e.g. \path\to\file or \server\share\path\to\file when using the MUP).
As you may guess a WinFsp file system creates a \Device\VolumeXYZ device and listens for messages such as OPEN \path\to\file. The situation is slightly more complicated when the MUP is involved: the MUP receives messages for prefixed paths such as \server\share\path\to\file. For this reason the MUP allows kernel drivers to register interest in particular prefixes. WinFsp uses this functionality to tell the MUP that when it sees a message with the prefix \server\share it should really forward this message to the device at \Device\VolumeXYZ.
(Please note that the above discussion is quite simplified, but the gist of it is correct.)
You ask: " Does the actual value of UNC path matter?"
The MUP and WinFsp do not interpret the prefix in any special way. However you should be aware of conflicts with other providers; for example, I would not have a prefix that conflicts with a NAS server on my network. I also recommend that prefixes follow the general syntax \FileSystemClass\FileSystemInstance for frictionless operation.
To view this discussion on the web visit https://groups.google.com/d/msgid/winfsp/976509df-5c8b-4f1a-a3e6-0842f87b5664n%40googlegroups.com.
Siyuan Ren
Siyuan Ren
- Is the network mapped drive handled differently by Windows? Like no caching or no indexing.
- Can we omit the mount point when we have the volume prefix, given that the volume prefix is already a file path.
Bill Zissimopoulos
Hello:
· Is the network mapped drive handled differently by Windows? Like no caching or no indexing.
Yes, it may be handled differently.
In general the OS core handles "disk" file systems and "network" file systems similarly (with some exceptions – e.g. you cannot mount a network file system as a directory).
However some apps (e.g. Explorer) handle the file system differently depending on its type (e.g. I seem to recall that some versions of Explorer will disable image thumbnails on a network drive). Unfortunately the different behaviors are not documented and may differ across OS versions.
· Can we omit the mount point when we have the volume prefix, given that the volume prefix is already a file path.
Yes, you can omit the mount point. This means your file system will only be accessible using UNC syntax (\\Class\Instance\Path) and not as a drive (X:\Path).
Bill
From: win...@googlegroups.com <win...@googlegroups.com>
On Behalf Of Siyuan Ren
Sent: Thursday, March 17, 2022 3:40 AM
To: WinFsp <win...@googlegroups.com>
Subject: Re: [winfsp] How to mount as network drive in FUSE API
I have more questions when I am about to implement this in my fuse program
· Is the network mapped drive handled differently by Windows? Like no caching or no indexing.
· Can we omit the mount point when we have the volume prefix, given that the volume prefix is already a file path.
Thanks
On Wednesday, November 10, 2021 at 7:21:08 AM UTC+8 Siyuan Ren wrote:
That clears all my confusion.
On Wed, Nov 10, 2021 at 01:26 Bill Zissimopoulos <bill...@navimatics.com> wrote:
Windows has a few different namespaces.
· There is the NTOS namespace (often called the Object Manager namespace) where all Windows objects live.
o This is the primary Windows namespace and all other namespaces are translated to this one.
· There are the Win32 drive namespaces (instead of a single file tree as in UNIX, you have a forest of trees A:, B:, C:, etc.)
o A Win32 path X:\path\to\file may correspond to the NTOS path \Device\VolumeXYZ\path\to\file.
· There is the UNC (Universal Naming Convention) namespace, which in general looks like \\server\share\path\to\file
o A UNC path \\server\share\path\to\file corresponds to the NTOS path \Device\Mup\server\share\path\to\file.
To view this discussion on the web visit https://groups.google.com/d/msgid/winfsp/ef36ce31-1a69-4acc-a449-e6dbd98e45c3n%40googlegroups.com.
Siyuan Ren
Bill Zissimopoulos
Hello:
I tried to call fuse_main with securefs -f -ouid=-1,gid=-1,umask=0 --VolumePrefix=\securefs\test -o fsname=securefs -o subtype=securefs
The result is confusing:
I still have drive Z: (even though I do not specify a drive letter) marked \\securefs\test, but not under "Network Path"
Re: drive Z:
I missed that you were doing this through FUSE and `fuse_main`.
It is possible to have a file system without a mountpoint when using the native WinFsp API. It is also possible to do this in FUSE, but not when you use `fuse_main`. The problem is that the WinFsp `fuse_main_real` implementation calls `fuse_mount` with a mountpoint and when no mountpoint is supplied it defaults to mounting as the next available drive counting downwards from drive Z:
https://github.com/winfsp/winfsp/blob/v1.10/src/dll/fuse/fuse_main.c#L142
Re: mounted as \\securefs\test but not appearing under Network in Explorer.
This is by design. The issue here is that there is no real host named "securefs" in your network, so it was sensible (in my mind) not to have it listed under Network in Explorer.
However you should be able to see your file system when you do `net use` because this lists "mapped network drives". For example here is the output of `net use` on my machine:
⟩ net use
New connections will not be remembered.
Status Local Remote Network
-------------------------------------------------------------------------------
H: \\hubfs\github.com WinFsp.Np
The command completed successfully.
Bill
From: Siyuan Ren <nethe...@gmail.com>
Sent: Sunday, March 20, 2022 6:16 AM
To: Bill Zissimopoulos <bill...@navimatics.com>
Cc: WinFsp <win...@googlegroups.com>
Subject: Re: [winfsp] How to mount as network drive in FUSE API
I tried to call fuse_main with securefs -f -ouid=-1,gid=-1,umask=0 --VolumePrefix=\securefs\test -o fsname=securefs -o subtype=securefs
The result is confusing:
I still have drive Z: (even though I do not specify a drive letter) marked \\securefs\test, but not under "Network Path"
Siyuan Ren
This is by design. The issue here is that there is no real host named "securefs" in your network, so it was sensible (in my mind) not to have it listed under Network in Explorer.
It is also possible to do this in FUSE, but not when you use `fuse_main`. The problem is that the WinFsp `fuse_main_real` implementation calls `fuse_mount` with a mountpoint and when no mountpoint is supplied it defaults to mounting as the next available drive counting downwards from drive Z:
Bill Zissimopoulos
Can we disable that in some way, like supplying an empty string as the mount point?
Unfortunately the fuse_mount API treats an empty mount point as an instruction to mount on the next available drive counting backwards from drive Z:
https://github.com/winfsp/winfsp/blob/v1.10/src/dll/fuse/fuse.c#L184
Your only option if you want this behavior is to provide your own implementation of fuse_main_real for WinFsp and not call fuse_mount. You can base it on WinFsp's own implementation:
https://github.com/winfsp/winfsp/blob/v1.10/src/dll/fuse/fuse_main.c#L125-L183
You can ignore all the stuff about "env" which is there to allow the same FUSE implementation to be used by Windows and Cygwin. You can also ignore daemonization and signal handlers (assuming your file system runs on Windows and not Cygwin).
Bill
From: win...@googlegroups.com <win...@googlegroups.com>
On Behalf Of Siyuan Ren
Sent: Monday, March 21, 2022 2:15 PM
To: Bill Zissimopoulos <bill...@navimatics.com>
Cc: WinFsp <win...@googlegroups.com>
Subject: Re: [winfsp] How to mount as network drive in FUSE API
This is by design. The issue here is that there is no real host named "securefs" in your network, so it was sensible (in my mind) not to have it listed under Network in Explorer.
--
You received this message because you are subscribed to the Google Groups "WinFsp" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
winfsp+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/winfsp/CAPhtH6YmNtqiD%2BywOEE0eRKfABCWqK-50uH6%3DCACqn4SKqENAA%40mail.gmail.com.