I’m looking to replace an existing legacy file system filter driver
with a Filter Manager-based filter driver in order to improve
compatibility and future maintenance. The driver intends to filter
only network redirector file system drivers on XP/2003/Vista.
Everything the existing filter does fits within the Filter Manager
architecture, except for some optimization that the legacy filter
performed during the IOCTL_REDIR_QUERY_PATH IOCTLs sent from MUP.
(There are paths the filter knows do not belong to the redirector
being filtered. To preempt avoidable delay for the interactive
user/process any time MUP chooses to call with one of these paths, the
IOCTL_REDIR_QUERY_PATH is completed as unclaimed without letting the
redirector process it. This same preemption is also occurring for any
network providers that call their redirector directly on IRP_MJ_CREATE
with one of these paths.)
Although I haven’t seen direct documentation on this point, I’m
presuming the reason for not seeing the IOCTL_REDIR_QUERY_PATH IOCTLs
exposed through the Filter Manager callbacks is logical.
While deciding what this will mean for the project, I wanted to post
the scenario to this list in case there are corrections or suggestions
this brings to mind for anyone. Thanks.
(Yes, MUP has its own scheme for using the network provider order to
optimize IOCTL_REDIR_QUERY_PATH and caching the results. This filter
still knows information that improves the user experience any time the
MUP cache and/or the network provider order didn’t prevent the call
from being made to the redirector being filtered.)
Alan Adams
On Vista can UNC provider register by FsRtlRegisterUncProviderEx(). The device name which is provided to MUP by FSD is unnamed, so there is no legal way for attaching to this device for filtering of IOCTL_REDIR_QUERY_PATH (or IOCTL_REDIR_QUERY_PATH_EX). To be honest I do not understand the background, so why you need to filter these requests. I am just providing an info. Also I guess these requests can beasynchronous on Vista, so they can be canceled. MUP creates symbolic link to its device, so you need attach to MUP device. Note that the old way of registering is still supported (FsRtlRegisterUncProvider()).
xxxxx@xythos.com wrote:
To be honest I do not understand the background, so why you
need to filter these requests. I am just providing an info.
There is not what I would call “spectacular effect”, but the point of
the filter is to try and shape the Windows performance with our
third-party network redirector present to be closer, where possible,
to the performance Windows has without an additional redirector
present.
e.g. There are calls down to the LanMan redirector with paths
involving server names we know are ours. And which we already claim
by UNC provider and by network provider, but they are being sent down
to LanMan anyway for one reason or another. For example, with IPC$ or
other reserved share name on a IRP_MJ_CREATE call, or via UNC query if
our provider intentionally isn’t primary in the provider order.
In the cases where we know a particular name doesn’t represent a
system that also provides CIFS/SMB services, preventing LanMan from
attempting to process this path just saves whatever short or long
delay LanMan will incur, if and when such a call is made.
Might the reason why the Filter Manager framework doesn’t expose the
IOCTL_REDIR_QUERY_PATH when its occurring be because MUP sends this
IOCTL through a different device object than Filter Manager is
attached to?
Yes I agree, Vista changed a few features of how a Vista-level file
system interacts with MUP. Other than trying to implement on the
Filter Manager framework, I haven’t looked beyond the existing XP/2003
platform with regard to this project.
Alan Adams
>Might the reason why the Filter Manager framework doesn’t expose the
IOCTL_REDIR_QUERY_PATH when its occurring be because MUP sends this
IOCTL through a different device object than Filter Manager is
attached to?
Probably yes, so it doesn’t create an impression that you can filter it on all OSs. Also I guess redirectors are not mini-filters’s point of interest.
-bg
IOCTL_REDIR_QUERY_PATH as noted below is initiated by MUP and sent to redirectors, so that one of them can claim the UNC path. If you wanted to write a UNC provider, you should write a redirector, not a minifilter. Minifilters are meant to be higher up in the stack (beginning Vista) above MUP.
Ravi
From: xxxxx@lists.osr.com [xxxxx@lists.osr.com] On Behalf Of xxxxx@xythos.com [xxxxx@xythos.com]
Sent: Wednesday, February 13, 2008 1:34 AM
To: Windows File Systems Devs Interest List
Subject: RE:[ntfsd] Filtering IOCTL_REDIR_QUERY_PATH
Might the reason why the Filter Manager framework doesn’t expose the
IOCTL_REDIR_QUERY_PATH when its occurring be because MUP sends this
IOCTL through a different device object than Filter Manager is
attached to?
Probably yes, so it doesn’t create an impression that you can filter it on all OSs. Also I guess redirectors are not mini-filters’s point of interest.
-bg
NTFSD is sponsored by OSR
For our schedule debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars
You are currently subscribed to ntfsd as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
Ravi Pudipeddi wrote:
> IOCTL_REDIR_QUERY_PATH as noted below is initiated by MUP and
> sent to redirectors, so that one of them can claim the UNC path.
> If you wanted to write a UNC provider, you should write a
> redirector, not a minifilter. Minifilters are meant to be higher
> up in the stack (beginning Vista) above MUP.
No intention to /write/ a UNC provider in this context; intention is
to /filter/ a UNC provider. i.e. Same as you might filter and perform
extra work on an IRP_MJ_CREATE being sent to a given redirector, the
intention here is to filter and perform extra work during an
IOCTL_REDIR_QUERY_PATH being sent to a given redirector.
Alan Adams