I’ve been very puzzled in public on the ntfsd mailing list lately.
I thin I’ve managed to work out the relationship between my name
providers (as called by another minifilter) and my name providers (as
called from my own filter processing an IRP).
Name provider when called from filters which might change an IRP
filename are somewhat speculative and are possibly being used to answer
a “what if” question.
When the IRP reaches my filter I MUST then do any name changes of the
type that my name providers had been suggesting would be done.
i.e. if my name functions had been converting name A to name B, I’d
better actually do it now I’ve got an IRP with name A.
I think thats all.
Sam
* Sam Liddicott wrote, On 03/11/09 11:32:
I’ve been very puzzled in public on the ntfsd mailing list lately.
I thin I’ve managed to work out the relationship between my name
providers (as called by another minifilter) and my name providers (as
called from my own filter processing an IRP).
Name provider when called from filters which might change an IRP
filename are somewhat speculative and are possibly being used to answer
a “what if” question.
When the IRP reaches my filter I MUST then do any name changes of the
type that my name providers had been suggesting would be done.
i.e. if my name functions had been converting name A to name B, I’d
better actually do it now I’ve got an IRP with name A.
I think thats all.
not quite. (though just for information)
I’m issuing STATUS_REPARSE from IRP_MJ_CREATE, and some of these
create’s are for name service functions.
This means that the IRP handler for a rename sees the destination file
with the opened form of
??\P:\dir\file.exe
and when I resolve it using FltGetDestinationFileInfom (request from
current provider) and my name provider only sees the re-parsed path
because another IPR_MJ_CREATE is issued first on:
\Device\Mup;LanmanRedirector;P:0000052de\server\share\dir
which I return STATUS_REPARSE for and then my name provider is called
with the re-parsed path.
This is strange to me as it is an example (contrary to what I said
above) of me having to fix something up in a create BEFORE I can ever
get to see it in one of my name functions… the pattern above was that
first my name functions would be prepared to tell the sort of lie my IRP
handler was going to construct (if an earlier filter gets
FileInformation), and then my IRP handler constructs the lie.
I guess that if I didn’t do re-parse, but just replaced the name and
continued, that my name provider functions would not see the corrected
name but the incoming name as given above (\Device\Mup;Lanman etc etc).
Sam
Yeah, name providers get the added bonus of having to work on operations that are yet to happen and on files that are yet to be opened. For example a name provider might see a query for a name for a FILE_OBJECT it never saw an open for (a minifilter above is querying names in preCreate). In the general case, any time a minifilter above the name provider is asking for a name, the name provider callbacks will be called before the operation reaches the name provider.
However, there usually is a FLT_CALLBACK_DATA structure from which the name provider can tell what the operation is (not that it matters in most cases).
Regards,
Alex.
This posting is provided “AS IS” with no warranties, and confers no rights.