Brian,
I agree with your complaint about the IRP in this API. You will notice
that there is no other case where you will see an IRP in filter manager.
When implementing the filter manager we talked about a couple of ways of
solving this:
-
Convert the IRP to a callback data. This seemed like a lot of
overhead since we would need to allocate two callback data structures
for this operation.
-
Move the parameters stored in the IRP into FLT_PARAMTERS. This would
have caused the size of the FLT_PARAMTERS structure to increase for all
operations since we need all of the parameters for create and query
information at the same time.
In the end all of this seemed like unnecessary overhead for an operation
that is supposed to be “fast”. The IRP in this case is nothing more
then a structure for holding the parameters for this operation. In that
sense it is not much different from the file information class
structures or the FSCTRL structures we use in other operations.
Neal Christiansen
Microsoft File System Filter Group Lead
This posting is provided “AS IS” with no warranties, and confers no
rights
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Brian Collins
Sent: Monday, October 11, 2004 7:39 AM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] FastIoQueryOpen and Filter Manager
Thanks Tony,
That clears it up. I can see now that it is NOT just some sort of fast
open.
For now, I will just return FLT_PREOP_DISALLOW_FASTIO, and that works
fine.
In future (for speed) I will handle it just as you describe.
Brian
PS. Shame about the Irp in the parameters - it messes up an otherwise
very
clean Filter Manager API.
“Tony Mason” wrote in message news:xxxxx@ntfsd…
I generally explain this fast I/O routine as the equivalent of rolling
up create, query information, cleanup and close all in a single
operation. Thus, from a filter model I think it IS reasonable to call
this out because it does not overlap precisely with any one other
operation.
Regards,
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Brian Collins
Sent: Monday, October 11, 2004 4:49 AM
To: ntfsd redirect
Subject: Re:[ntfsd] FastIoQueryOpen and Filter Manager
Molly,
This makes me wonder a bit though.
I understood that the Filter Manager generally combines multiple ways of
achieving the same effect. So (for example) a FastIO “read” operation
would
be vectored onto the registered handler for IRP_MJ_READ. And often that
handler would not need to look at the flags to find out if it was an IRP
or
FastIO operation.
As you describe it, IRP_MJ_NETWORK_QUERY_OPEN is just a pseudo-IRP for
FastIoQueryOpen, which I can handle in a similar manner to
IRP_MJ_CREATE.
But it worries me slightly that you see the need for a separate
pseudo-IRP
for this, where there is no separate pseudo-IRP for FastIoRead.
So, is there something significant about IRP_MJ_NETWORK_QUERY_OPEN which
makes it different and I need to be aware of, and which implies that it
cannot be simply handled just like IRP_MJ_CREATE?
Thanks again
Brian
“Brian Collins” wrote in message
news:xxxxx@ntfsd…
> Thanks Molly,
>
> That pointed me in the right direction. I had got thrown off course by
the
> use of the word “NETWORK”, in the pseudo-IRP name so had not checked
that
> more carefully.
>
> Actually I was registering for the IRP_MJ_NETWORK_QUERY_OPEN
operation.
> But I was using my “standard” fastIO handler:
>
> if ( FltGetStreamHandleContext( FltObjects->Instance,
> FltObjects->FileObject, &pContext ) == STATUS_SUCCESS )
> {
> FltReleaseContext( pContext );
> return FLT_PREOP_DISALLOW_FASTIO;
> }
> return FLT_PREOP_SUCCESS_NO_CALLBACK;
>
> But on IRP_MJ_NETWORK_QUERY_OPEN I don’t yet have a stream handle
> context - do I??? I now look at FltObjects->FileObject->FileName
instead
> and all is well – till the next bug!
>
> Brian
>
> “Molly Brown” wrote in message
> news:xxxxx@ntfsd…
> Hi Brian,
>
> It sounds like you are not registering from the
> IRP_MJ_NETWORK_QUERY_OPEN operation. The filter manager defines some
> new IRP_MJ codes for Fast IO operations which don’t have IRP
> equivalents, and this is one such Fast IO operation. If you register
> for this operation, you will get called when the FastIoQueryOpen is
> issues and you can return your meaningful file object.
>
> Thanks,
> Molly Brown
> Microsoft Corporation
>
> This posting is provided “AS IS” with no warranties and confers no
> rights.
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Brian Collins
> Sent: Friday, October 08, 2004 7:45 AM
> To: Windows File Systems Devs Interest List
> Subject: [ntfsd] FastIoQueryOpen and Filter Manager
>
> How (if at all) should filters see and process FastIoQueryOpen?
>
> I have just returned to my filter driver port from a 4 month diversion
> into other areas. So I am somewhat rusty. I am also using IFS/DDK
> 3790.1194 in case that is important.
>
> The problem I am seeing in my testing is that somewhere in the filter
> manager and/or IO manager, a create is failing as PATH_NOT_FOUND. But
> this happens without calling my filter which would (if asked)
> successfully open the non-existent path and return a meaningful file
> object. The legacy filter driver has been been doing this for over six
> years.
>
> When I trace it at a higher level using FileMon, the successful legacy
> run
> shows:
> 53 14:18:15 IEXPLORE.EXE:1364 OPEN C:\My
> Intranets\iOraSearch\HTTP\www.iora.com\index.html SUCCESS Options:
Open
> Access: All
> 54 14:18:15 IEXPLORE.EXE:1364 QUERY INFORMATION C:\My
> Intranets\iOraSearch\HTTP\www.iora.com\index.html SUCCESS
> FileBasicInformation
> 55 14:18:15 IEXPLORE.EXE:1364 CLOSE C:\My
> Intranets\iOraSearch\HTTP\www.iora.com\index.html SUCCESS
>
> whereas the filter manager run onlu shows:
> 36 14:33:45 IEXPLORE.EXE:1136 QUERY INFORMATION C:\My
> Intranets\iOraSearch\HTTP\www.iora.com\desktop.ini PATH NOT FOUND
> Attributes: Error
>
> My reading of earlier postings suggests that the “singleton” QUERY
> INFORMATION could arise from a ZwQueryInformationFile. But I believe
> that would use a FastIoQueryOpen to check first with my filter. The
> legacy implemtation of FastIoQueryOpen returns FALSE. I always see
> CREATE IRPs there.
>
> I can find nothing in the Filter Manager that allows me to handle
> FastIoQueryOpen. Is that all meant to be hidden within the Filter
> Manager?
> If so, why is it failing to ask my filter to open a file?
>
> Are the issues and questions clear enough from this?
>
> Brian Collins, iOra
>
>
>
> —
> 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
>
>
>
>
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
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