DosDevice for driver object used in FsRtlRegisterUncProviderEx

NTFSD
1

The intention of FsRtlRegisterUncProviderEx would appear to be that
the device names which used to reference the device object directly
(e.g. “\Device\Foo”) now are guaranteed to pass through MUP (e.g.
“\Device\Mup;Foo”) where MUP in turn will reference the otherwise
unnamed device object.

If that’s true, is there any reason for not creating a DosDevice name
with the same target MUP constructed to ease my Win32 user-mode
application’s ability to send IRP_MJ_DEVICE_CONTROL-type requests to
the file system driver?

(i.e. Use ZwQuerySymbolicLinkObject to learn what path MUP used for
the “\Device\Foo” symbolic link, and then create our own DOS device
“\DosDevices\FooDriver” that uses that same target, e.g.
“\Device\Mup;Foo”.)

Thereby maintaining “the intention” of having all access be visible to
MUP even when the user-mode Win32 caller is calling CreateFile for
“\.\FooDevice”.

(Hmm, what about a symbolic link to a symbolic link. I don’t see many
examples of that, but \DosDevices\PRN seems to be one. i.e. Instead
of bothering to learn what target MUP created for the symbolic link it
created, just create my DosDevices symbolic link as one that points
to the symbolic link MUP created, which in turn then references the
MUP-based device path.)

Or is there more to the picture of “the intention” than I’m including
here that precludes having other symbolic links that point to the same
MUP-based device path.

All I’m really trying to avoid is the need for user-mode Win32 /
Platform SDK callers to come up with a prototype for ZwCreateFile just
to access a device name like “\Device\Foo”. Which is not really
/that/ hard, so if there are even minor reasons to avoid maintaining
the DosDevices link, that would probably be enough to quash it.

Alan Adams

2

If you want to direct IOCTLs to your redirector directly (and to an open handle), it’s best to create a separate named device object (a ‘conrol’ device object) & symbolic link to go with it. You really don’t need to route those through MUP.
ravi

From: xxxxx@lists.osr.com on behalf of Alan Adams
Sent: Wed 5/17/2006 1:51 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] DosDevice for driver object used in FsRtlRegisterUncProviderEx

The intention of FsRtlRegisterUncProviderEx would appear to be that
the device names which used to reference the device object directly
(e.g. “\Device\Foo”) now are guaranteed to pass through MUP (e.g.
“\Device\Mup;Foo”) where MUP in turn will reference the otherwise
unnamed device object.

If that’s true, is there any reason for not creating a DosDevice name
with the same target MUP constructed to ease my Win32 user-mode
application’s ability to send IRP_MJ_DEVICE_CONTROL-type requests to
the file system driver?

(i.e. Use ZwQuerySymbolicLinkObject to learn what path MUP used for
the “\Device\Foo” symbolic link, and then create our own DOS device
“\DosDevices\FooDriver” that uses that same target, e.g.
“\Device\Mup;Foo”.)

Thereby maintaining “the intention” of having all access be visible to
MUP even when the user-mode Win32 caller is calling CreateFile for
“\.\FooDevice”.

(Hmm, what about a symbolic link to a symbolic link. I don’t see many
examples of that, but \DosDevices\PRN seems to be one. i.e. Instead
of bothering to learn what target MUP created for the symbolic link it
created, just create my DosDevices symbolic link as one that points
to the symbolic link MUP created, which in turn then references the
MUP-based device path.)

Or is there more to the picture of “the intention” than I’m including
here that precludes having other symbolic links that point to the same
MUP-based device path.

All I’m really trying to avoid is the need for user-mode Win32 /
Platform SDK callers to come up with a prototype for ZwCreateFile just
to access a device name like “\Device\Foo”. Which is not really
/that/ hard, so if there are even minor reasons to avoid maintaining
the DosDevices link, that would probably be enough to quash it.

Alan Adams

Questions? First check the IFS FAQ at https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

3

Typo below - I meant : (and *not* to an open file handle)

From: Ravisankar Pudipeddi
Sent: Wed 5/17/2006 9:55 PM
To: Windows File Systems Devs Interest List; Windows File Systems Devs Interest List
Subject: RE: [ntfsd] DosDevice for driver object used in FsRtlRegisterUncProviderEx

If you want to direct IOCTLs to your redirector directly (and to an open handle), it’s best to create a separate named device object (a ‘conrol’ device object) & symbolic link to go with it. You really don’t need to route those through MUP.
ravi

From: xxxxx@lists.osr.com on behalf of Alan Adams
Sent: Wed 5/17/2006 1:51 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] DosDevice for driver object used in FsRtlRegisterUncProviderEx

The intention of FsRtlRegisterUncProviderEx would appear to be that
the device names which used to reference the device object directly
(e.g. “\Device\Foo”) now are guaranteed to pass through MUP (e.g.
“\Device\Mup;Foo”) where MUP in turn will reference the otherwise
unnamed device object.

If that’s true, is there any reason for not creating a DosDevice name
with the same target MUP constructed to ease my Win32 user-mode
application’s ability to send IRP_MJ_DEVICE_CONTROL-type requests to
the file system driver?

(i.e. Use ZwQuerySymbolicLinkObject to learn what path MUP used for
the “\Device\Foo” symbolic link, and then create our own DOS device
“\DosDevices\FooDriver” that uses that same target, e.g.
“\Device\Mup;Foo”.)

Thereby maintaining “the intention” of having all access be visible to
MUP even when the user-mode Win32 caller is calling CreateFile for
“\.\FooDevice”.

(Hmm, what about a symbolic link to a symbolic link. I don’t see many
examples of that, but \DosDevices\PRN seems to be one. i.e. Instead
of bothering to learn what target MUP created for the symbolic link it
created, just create my DosDevices symbolic link as one that points
to the symbolic link MUP created, which in turn then references the
MUP-based device path.)

Or is there more to the picture of “the intention” than I’m including
here that precludes having other symbolic links that point to the same
MUP-based device path.

All I’m really trying to avoid is the need for user-mode Win32 /
Platform SDK callers to come up with a prototype for ZwCreateFile just
to access a device name like “\Device\Foo”. Which is not really
/that/ hard, so if there are even minor reasons to avoid maintaining
the DosDevices link, that would probably be enough to quash it.

Alan Adams

Questions? First check the IFS FAQ at https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com