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
cheers
Le 17/02/2010 14:59, Thomas a �crit :
Thomas
is it possible to pass DokanOptions.NetworkDrive also from C-Sharp to
the Dokan-Library?
Kind Regards,
-Ingo
> --
> 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.
>
>
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.
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
>
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
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
>
#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
Thanks
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.
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:
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.
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
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.
>
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.
>
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.
On 5 Apr., 12:24, Hiroki Asakawa <asa...@gmail.com> wrote:
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
On 6 Apr., 20:47, Hiroki Asakawa <asa...@gmail.com> wrote:
> Hello,
>