Trouble with Dokan driver mounted as Network drive

706 views
Skip to first unread message

Thomas

unread,
Feb 17, 2010, 8:59:22 AM2/17/10
to Dokan
Hi all,

I'm trying to mount our file system as a Network drive
(FILE_DEVICE_NETWORK_FILE_SYSTEM when creating the device). At first,
this seems to work perfectly, but when I want to open files with the
VLC media player or with Powerpoint, the programs complain they
couldn't open the files.

PPT says: "The path or file name for W:\TomTest6\Fotos\copy.ppt is
invalid. Please check that the path and file name are correct."

Does that ring a bell for anybody? The weird thing is that this works
as soon as I return "FILE_DEVICE_DISK_FILE_SYSTEM" for the
FileFsDeviceInformation in sys/volume.c. I just don't get it.

Thomas

Aymeric MUNTZ

unread,
Feb 17, 2010, 10:20:19 AM2/17/10
to do...@googlegroups.com
Where did you get this information that it is possible to mount the
filesystem as a network drive?
I didn't find anything on this!

cheers

Le 17/02/2010 14:59, Thomas a �crit :

Thomas

unread,
Feb 17, 2010, 10:42:06 AM2/17/10
to Dokan
Use the source, Luke!
Hiroki has built in network-drive support a while ago. I'm porting
that back to 0.4.2. and I'm going bonkers because I'm getting strange
errors!

Thomas

ingobaab

unread,
Feb 17, 2010, 12:30:33 PM2/17/10
to Dokan
Hi Luke (and Hiroki) ;-)

is it possible to pass DokanOptions.NetworkDrive also from C-Sharp to
the Dokan-Library?

Kind Regards,
-Ingo

Hiroki Asakawa

unread,
Feb 17, 2010, 5:39:08 PM2/17/10
to do...@googlegroups.com
On Wed, Feb 17, 2010 at 6:30 PM, ingobaab <ingo...@googlemail.com> wrote:
> Hi Luke (and Hiroki) ;-)
>
> is it possible to pass DokanOptions.NetworkDrive also from C-Sharp to
> the Dokan-Library?
Yes, at least the latest version of Dokan.NET on the svn pository supports
DokanOperations.NetworkDrive.
You need to compile and install dokannp.dll.
http://groups.google.com/group/dokan/browse_thread/thread/8bb46ff0cda279fd/

> --
> You received this message because you are subscribed to the Google Groups "Dokan" group.
> To post to this group, send email to do...@googlegroups.com.
> To unsubscribe from this group, send email to dokan+un...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/dokan?hl=en.
>
>

Hiroki Asakawa

unread,
Feb 17, 2010, 5:42:14 PM2/17/10
to do...@googlegroups.com
Hi, Thomas

Thank you for your report. MS office always has some problems..
I haven't tested network drive option for a while. Let me investigate
this weekend.

Thomas

unread,
Feb 18, 2010, 4:47:33 AM2/18/10
to Dokan
Actually, I've found out something: if I change the value returned for
WWNC_NET_TYPE, the behaviour changes. I am currently using 0x250025,
which seems to work ok. It is also what Parallels Desktop uses to
mount Mac-Directories in a Windows virtual machine.

Why Windows would react to those well known values is totally beyond
me. I want me some of the crack they're smoking ;-)

On 17 Feb., 23:42, Hiroki Asakawa <asa...@gmail.com> wrote:
> Hi, Thomas
>

Message has been deleted

Hiroki Asakawa

unread,
Feb 18, 2010, 4:37:21 PM2/18/10
to do...@googlegroups.com
Hi, Thomas

On Thu, Feb 18, 2010 at 10:48 AM, Thomas <t.s.m...@gmail.com> wrote:
> Actually, I've found out something: if I change the value returned for
> WWNC_NET_TYPE, the behaviour changes. I am currently using 0x250025,
> which seems to work ok. It is also what Parallels Desktop uses to
> mount Mac-Directories in a Windows virtual machine.

I tried WNNC_NET_RDR2SAMPLE, WNNC_NET_SMB and 0x250025,
but couldn't open the office file.
BTW, WNNC_NET_RDR2SAMPLE is 0x250000, so 0x250025 is a subtype of
WNNC_NET_RDR2SAMPLE.

When I returned FILE_DEVICE_DISK_FILE_SYSTEM in
FileFsDeviceInformation, it worked!
Probably WNNC_NET_TYPE is irrelevant to this issue.
Some import features may be missing as FILE_DEVCE_NETWORK_FILE_SYSTEM.

Thanks,

>
> Why Windows would react to those well known values is totally beyond
> me. I want me some of the crack they're smoking ;-)
>
> On 17 Feb., 23:42, Hiroki Asakawa <asa...@gmail.com> wrote:

>> Hi, Thomas

Thomas

unread,
Feb 19, 2010, 4:26:07 AM2/19/10
to Dokan
Hi Hiroki,

Upon further investigation, I agree that the net type is irrelevant.
I'll keep debugging; returning FILE_DEVICE_DISK_FILE_SYSTEM still
sounds like a hack.

Thomas

On 18 Feb., 22:37, Hiroki Asakawa <asa...@gmail.com> wrote:
> Hi, Thomas
>

Thomas

unread,
Feb 19, 2010, 7:54:14 AM2/19/10
to Dokan
I have made the following example to highlight the problem (done with
visual c++ express)

#include "stdafx.h"
#include <io.h>
#include <fcntl.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <share.h>
#include <windows.h>

int _tmain(int argc, _TCHAR* argv[])
{
if (argc < 2) {
return -1;
}
if (_wopen(argv[1], O_RDONLY, S_IREAD) == -1) {
printf("wopen: %d for %S\n", errno, argv[1]);
} else {
printf("wopen ok: %d for %S\n", errno, argv[1]);
}

}
#include "stdafx.h"
#include <io.h>
#include <fcntl.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <share.h>
#include <windows.h>

int _tmain(int argc, _TCHAR* argv[])
{
if (argc < 2) {
return -1;
}
if (_wopen(argv[1], O_RDONLY, S_IREAD) == -1) {
printf("wopen: %d for %S\n", errno, argv[1]);
} else {
printf("wopen ok: %d for %S\n", errno, argv[1]);
}

}

I always get errno == EACCES (Permission denied) when run it against
the dokan drive, and it works against a file on c:

I figure the net provider needs to authorize the access somehow?

Thomas

Message has been deleted

thrruss

unread,
Feb 22, 2010, 4:02:12 AM2/22/10
to Dokan
Did you integrate an efficient network drive feature in Dokan 0.5?
Did you solve that Office problem?

Thanks

Thomas

unread,
Feb 22, 2010, 9:27:00 AM2/22/10
to Dokan
I have found the following in the NTFS internals book:

FileFsDevicelnf ormation (enumerated type value = 4)
The caller expects to receive information about the type of physical
or logical device on which the logical volume has been mounted:
typedef struct _FILE_FS_DEVICE_INFORMATION {
DEVICE_TYPE DeviceType;
ULONG Characteristics;
} FILE_FS_DEVICE_INFORMATION, *PFILE_FS_DEVICE_INFORMATION;

The DeviceType field value can be set by your FSD to an appropriate
device type. For example, CDFS specifies the DeviceType value as
FILE_DEVICE_CD_ROM, while FASTFAT and NTFS use FILE_DEVICE_DISK
instead. For a network redirector, the DeviceType field can be set to
an appropriate value depending upon the type of connection made. If,
for example, the query volume information request is issued using a
file object representing an open instance of the network redirector
itself, the value could well be set to
FILE_DEVICE_NETWORK_FILE_SYSTEM.

The Characteristics field should be set to an appropriate value from
the following (one or more flag values can be set):

// Volume mounted on removable media.
#define FILE_REMOVABLE_MEDIA 0x00000001
#define FILE_READ_ONLY_DEVICE 0x00000002
#define FILE_FLOPPY_DISKETTE 0x00000004
#define FILE_WRITE_ONCE_MEDIA 0x00000008
#define FILE_REMOTE_DEVICE 0x00000010
ttdefine FILE_DEVICE_IS_MOUNTED 0x00000020
tfdefine FILE_VIRTUAL_VOLUME 0x00000040

Note that if you have designed a network redirector and if you set the
FILE_
REMOTE_DEVICE flag in the Characteristics field, the logical volume
cannot be reshared across the LAN Manager Network.

So I figure it is ok to return something other than
FILE_DEVICE_NETWORK_FILE_SYSTEM. FILE_DEVICE_VIRTUAL_DISK seems to
work fine for me.

Thomas

unread,
Mar 12, 2010, 7:26:18 AM3/12/10
to Dokan
An update:

I could get Windows media player to open mp3 file by registering the
dokan driver as a UNC provider (FsRTLRegisterUncProvider) and by
implementing the IOCTL_REDIR_QUERY_PATH.

Thomas schrieb:

Hiroki Asakawa

unread,
Mar 15, 2010, 6:39:01 PM3/15/10
to do...@googlegroups.com
Hi, Thomas

Thank you for useful information. FILE_FS_DEVICE_INFORMATION.DeviceType probably
should be the same value which was specified in IoCreateDevice (sys\init.c).
I want to enable to change Characteristics and DeviceType from user mode
and those value should be stored in DokanDCB.

For now, I changed the device type to FILE_DEVICE_VIRTUAL_DISK, which is
currently used in init.c.

Hiroki Asakawa

unread,
Mar 18, 2010, 7:45:58 PM3/18/10
to do...@googlegroups.com
Hello, Thomas

I tried to support FsRTLRegisterUncProvider, but failed.
FsRTLRegisterUncProvider returns 0xC0000103.
http://code.google.com/p/dokan/source/detail?r=112
What did you do to support FsRTLRegisterUncProvider?

Thomas

unread,
Mar 26, 2010, 12:55:44 PM3/26/10
to Dokan
I get a return code of 0xC000000E (no such device) now. I'm sure it
worked before my vacation (I remember distinctly getting the redirect
query ioctl, which I don't anymore). I will slog away at this some
more on monday.

Thomas

On 19 Mrz., 00:45, Hiroki Asakawa <asa...@gmail.com> wrote:
> Hello, Thomas
>
> I tried to support FsRTLRegisterUncProvider, but failed.

> FsRTLRegisterUncProvider returns 0xC0000103.http://code.google.com/p/dokan/source/detail?r=112


> What did you do to support FsRTLRegisterUncProvider?On Mon, Mar 15, 2010 at 11:39 PM, Hiroki Asakawa <asa...@gmail.com> wrote:
> > Hi, Thomas
>
> > Thank you for useful information. FILE_FS_DEVICE_INFORMATION.DeviceType probably
> > should be the same value which was specified in IoCreateDevice (sys\init.c).
> > I want to enable to change Characteristics and DeviceType from user mode
> > and those value should be stored in DokanDCB.
>
> > For now, I changed the device type to FILE_DEVICE_VIRTUAL_DISK, which is
> > currently used in init.c.
>

Thomas

unread,
Mar 30, 2010, 12:02:00 PM3/30/10
to Dokan
It seems you need to call FsRtlRegisterUNCProvicer with the context of
the system process:

http://www.osronline.com/showThread.cfm?link=32799

I figure you call it from an IOCTL?

Thomas

On 19 Mrz., 00:45, Hiroki Asakawa <asa...@gmail.com> wrote:

> Hello, Thomas
>
> I tried to support FsRTLRegisterUncProvider, but failed.

> FsRTLRegisterUncProvider returns 0xC0000103.http://code.google.com/p/dokan/source/detail?r=112


> What did you do to support FsRTLRegisterUncProvider?
>
> On Mon, Mar 15, 2010 at 11:39 PM, Hiroki Asakawa <asa...@gmail.com> wrote:
> > Hi, Thomas
>
> > Thank you for useful information. FILE_FS_DEVICE_INFORMATION.DeviceType probably
> > should be the same value which was specified in IoCreateDevice (sys\init.c).
> > I want to enable to change Characteristics and DeviceType from user mode
> > and those value should be stored in DokanDCB.
>
> > For now, I changed the device type to FILE_DEVICE_VIRTUAL_DISK, which is
> > currently used in init.c.
>

Hiroki Asakawa

unread,
Apr 5, 2010, 6:24:07 AM4/5/10
to do...@googlegroups.com
On Tue, Mar 30, 2010 at 6:02 PM, Thomas <t.s.m...@gmail.com> wrote:
> It seems you need to call FsRtlRegisterUNCProvicer with the context of
> the system process:
>
> http://www.osronline.com/showThread.cfm?link=32799
>
> I figure you call it from an IOCTL?

Yes, I called it from IOCTL. I made it called in system thread, but
still it returns
0xC0000103.

I checked on Windows7 x86 and it returns success! MUP was rewrote on
Vista, and that is the reason this works on 7 but doesn't on XP.

Thomas

unread,
Apr 6, 2010, 11:13:38 AM4/6/10
to Dokan
Did you call FsRtlRegisterUNCProvicerEx or FsRtlRegisterUNCProvicer ?

On 5 Apr., 12:24, Hiroki Asakawa <asa...@gmail.com> wrote:

Hiroki Asakawa

unread,
Apr 6, 2010, 2:47:59 PM4/6/10
to do...@googlegroups.com
Hello,

On Tue, Apr 6, 2010 at 5:13 PM, Thomas <t.s.m...@gmail.com> wrote:
> Did you call FsRtlRegisterUNCProvicerEx or FsRtlRegisterUNCProvicer ?

I call FsRtlRegisterUNCProvicer for both XP and 7.

Here is the change:
http://code.google.com/p/dokan/source/detail?r=133

Thomas

unread,
Apr 8, 2010, 4:11:23 AM4/8/10
to Dokan
0xc0000103 is STATUS_NOT_A_DIRECTORY? That makes no sense, does it?

On 6 Apr., 20:47, Hiroki Asakawa <asa...@gmail.com> wrote:
> Hello,
>

Thomas

unread,
Apr 8, 2010, 9:22:28 AM4/8/10
to Dokan
I've found out that XP tries to create a handle to the device object
with the "directory" flag set, which fails with STATUS_NOT_A_DIRECTORY
in sys/create.c. When create succeeds, the file system can be
registered as a UNC provider.
Reply all
Reply to author
Forward
0 new messages