I’m having my first knowing encounter with the path MUP is sending via
IOCTL_REDIR_QUERY_PATH_EX presumably after DFS Client has successfully
determined that a path involves a DFS Root.
The “visual hint” for such a query is that the path MUP sends contains
a prefix of both “the actual DFS namespace host server and DFS root”
followed by a “duplicate” path, which appears to be the actual logical
path the user or application attempted to use.
My question is: Is anyone aware of documented or undocumented hints I
can be looking for during IOCTL_REDIR_QUERY_PATH_EX that would help
identify “this path is being queried because it’s considered to be a
DFS Root”?
Tony Mason confirmed back in May 2012’s “Very strange WinXP DFS issue”
thread having seen these DFS root path queries hit
IOCTL_REDIR_QUERY_PATH_EX:
Tony Mason wrote:
> In at least some versions of Windows, DFS and MUP communicate with one another
> via information in FileObject->FsContext; you might wish to look at the contents
> of that field when you see this issue.
> …
> We have seen the doubled prefix thing in our own work as well (what’s even more
> frustrating is that we’ve seen it use LOGICAL duplication - such as
> \server\share<server or ip address>\share.… which makes it complicated to
> figure out these are “duplicates”). And as you note, once the file is opened
> a query of the name is different.
Am I missing a hint within the FSRTL_ADVANCED_FCB_HEADER itself, or
are we actually talking about undocumented contents of the presumably
private structure that lies beyond the RTL header?
Just looking for something slightly more “definitive” to react to
during IOCTL_REDIR_QUERY_EX, rather than “guessing” based on the
string path content at what might or might not be actual duplication
in the path prefix.
Thanks.
Alan Adams
Client for Open Enterprise Server
Micro Focus
xxxxx@microfocus.com
Are you trying to determine if the path is handled by your redirector?
While the parsing can be troublesome, it’s not too difficult to take it
piece by piece and make a decision on how much of the path your
redirector will handle. For example, I have taken the approach in past
implementations to pull out the \server\share portion, decide whether
my redirector handles it then move on to the next component. While the
next component may fail, your redirector would then get sent anything
which has the \server\share portion on it.
Pete
–
Kernel Drivers
Windows File System and Device Driver Consulting
www.KernelDrivers.com
866.263.9295
------ Original Message ------
From: “Alan Adams”
To: “Windows File Systems Devs Interest List”
Sent: 11/16/2016 3:23:11 PM
Subject: [ntfsd] IOCTL_REDIR_QUERY_PATH_EX for DFS Root-relative path
>I’m having my first knowing encounter with the path MUP is sending via
>IOCTL_REDIR_QUERY_PATH_EX presumably after DFS Client has successfully
>determined that a path involves a DFS Root.
>
>The “visual hint” for such a query is that the path MUP sends contains
>a prefix of both “the actual DFS namespace host server and DFS root”
>followed by a “duplicate” path, which appears to be the actual logical
>path the user or application attempted to use.
>
>My question is: Is anyone aware of documented or undocumented hints I
>can be looking for during IOCTL_REDIR_QUERY_PATH_EX that would help
>identify “this path is being queried because it’s considered to be a
>DFS Root”?
>
>Tony Mason confirmed back in May 2012’s “Very strange WinXP DFS issue”
>thread having seen these DFS root path queries hit
>IOCTL_REDIR_QUERY_PATH_EX:
>
>Tony Mason wrote:
>
>> In at least some versions of Windows, DFS and MUP communicate with
>>one another
>> via information in FileObject->FsContext; you might wish to look at
>>the contents
>> of that field when you see this issue.
>> …
>> We have seen the doubled prefix thing in our own work as well (what’s
>>even more
>> frustrating is that we’ve seen it use LOGICAL duplication - such as
>> \server\share<server or ip address>\share.… which makes it
>>complicated to
>> figure out these are “duplicates”). And as you note, once the file
>>is opened
>> a query of the name is different.
>
>Am I missing a hint within the FSRTL_ADVANCED_FCB_HEADER itself, or
>are we actually talking about undocumented contents of the presumably
>private structure that lies beyond the RTL header?
>
>Just looking for something slightly more “definitive” to react to
>during IOCTL_REDIR_QUERY_EX, rather than “guessing” based on the
>string path content at what might or might not be actual duplication
>in the path prefix.
>
>Thanks.
>
>Alan Adams
>Client for Open Enterprise Server
>Micro Focus
>xxxxx@microfocus.com
>
>—
>NTFSD is sponsored by OSR
>
>
>MONTHLY seminars on crash dump analysis, WDF, Windows internals and
>software drivers!
>Details at http:
>
>To unsubscribe, visit the List Server section of OSR Online at
>http:</http:></http:>
PScott wrote:
> Are you trying to determine if the path is handled by your redirector?
> While the parsing can be troublesome, it’s not too difficult to take it
> piece by piece and make a decision on how much of the path your
> redirector will handle. For example, I have taken the approach in past
> implementations to pull out the \server\share portion, decide whether
> my redirector handles it then move on to the next component. While the
> next component may fail, your redirector would then get sent anything
> which has the \server\share portion on it.
Thanks for the response. And I completely agree that what you’ve
described is the manner in which the IOCTL_REDIR_QUERY_PATH_EX
handling should approach claiming the path. Only the \server\share
prefix is meaningful to the decision MUP is making with this query.
There may or may not be more path present beyond \server\share in the
query, and the directories and/or files named in that additional path
may or may not currently exist. But regardless of any of that,
ultimately “\server\share” is still the redirector’s to claim, and
have future MUP paths sent directly to IRP_MJ_CREATE for this prefix.
That’s already the way in which our redirector behaves. When MUP
sends “\server\share\folder\desktop.ini” and either “folder” and/or
“desktop.ini” do not exist, we still successfully claim
“\server\share” in response to the IOCTL_REDIR_QUERY_PATH_EX query.
So when we receive what Tony described as “the doubled prefix thing”
for a DFS-involved path, we’re getting an IOCTL_REDIR_QUERY_PATH_EX
query for something like “\server\share\DNSorIPaddress\share”.
And we claim this no differently than the previous example: If
“\server\share” are ours, we claim just that prefix and ignore
whatever the intention of the rest was. Still thinking it was just a
non-existent directory name; but in this DFS case “the doubled prefix
thing” was actually there for DFS-specific reasons, and names things
that were never expected to be file system folders or files.
Note this does begin to touch on the details of the scenario I’m
actually intending to solve:
There is a CIFS/SMB-accessible share on this server, and its also a
DFS Namespace. Works 100% great with only MRxSMB present on the
Windows machine. Let’s call this path “\server\DFSRoot”.
This same server ALSO implements our redirector’s file access
protocol, and for consistently to the end users, the path that is
valid over our file access protocol is /also/ named
“\server\DFSRoot”. So that regardless of whether someone is using
CIFS or using our client, the path the application accesses is
“\FS1\ACCOUNTING” in either case, for example.
If you create such a scenario using just a normal CIFS share (without
involving a DFS Namespace), this seems to be exactly the scenario
Windows MUP intends to solve: Two redirectors (MRxSMB and ours) both
claim the same “\server\share” path, and so it’s up to MUP to refer
to the Windows Network Provider Order to decide which one “wins”.
But when the “CIFS share” is actually a DFS Root path in that
scenario, things break down.
As soon as we claim the “\server\DFSRoot” prefix during “the doubled
prefix thing” query, Windows access to the UNC path fails. Because
our redirector starts receiving IRP_MJ_CREATEs that contain “the
doubled prefix thing” in their paths, too. So instead of getting
“\server\share\folder\desktop.ini” in our redirector, we’re getting
“\server\DFSRoot\DNSorIPadderss\DFSRoot\folder\desktop.ini”, and our
IRP_MJ_CREATE returns PATH_NOT_FOUND because “DNSorIPaddress” does not
exist as a folder.
I’m guessing the IOCTL_REDIR_QUERY_PATH_EX query from MUP was
occurring on behalf of something DFS Client was doing, and DFS Client
and/or MUP presumed that only MRxSMB could be or would be claiming
this prefix that named a path which DFS Client has successfully
identified as a Microsoft DFS Namespace path.
Indeed, if I push “Microsoft Network Services” to the top of the
Windows Network Provider Order, the UNC path access does not break.
Since even though two redirectors still claimed the path by prefix,
now MRxSMB begins receiving the IRP_MJ_CREATES with “the doubled
prefix thing” and MRxSMB knows what to do with them.
Unfortunately “push Microsoft Network Services to the top of the
Windows Network Provider Order / above our redirector” is not
acceptable to our customer, and so I’m looking for other ways a
redirector might be able to identify or appropriately deal with this
seemingly Microsoft DFS-specific query hitting that is hitting
IOCTL_REDIR_QUERY_PATH_EX.
And so the first stop was to try and determine whether this
IOCTL_REDIR_QUERY_PATH_EX containing “the doubled prefix thing” can be
identified, using a method any more definitive than trying to “guess”
based on the parsing of the actual path that “DNSorIPaddress” /might/
not actually have meant a folder by that name.
Alan Adams
Client for Open Enterprise Server
Micro Focus
xxxxx@microfocus.com