I’ve got a minifilter driver that does some sort of file mirroring.
When I invoke FltClose, it sends IRP_MJ_CLEANUP below my minifilter, thus bypassing my IRP_MJ_CLEANUP handler. I thought, however, IRP_MJ_CLOSE on that file (when refcount drops to zero) still goes through the whole filesystem stack from the top to the bottom so that I can see it in my IRP_MJ_CLOSE handler. Surprisingly enough, my IRP_MJ_CLOSE handler never sees it. Is that by design or am I missing something here?
I’ve got a minifilter driver that does some sort of file mirroring.
When I invoke FltClose, it sends IRP_MJ_CLEANUP below my minifilter, thus bypassing my IRP_MJ_CLEANUP handler. I thought, however, IRP_MJ_CLOSE on that >file (when refcount drops to zero) still goes through the whole filesystem stack from the top to the bottom so that I can see it in my IRP_MJ_CLOSE >handler. Surprisingly enough, my IRP_MJ_CLOSE handler never sees it. Is that by design or am I missing something here?
This is one of the major ADVANTAGES of using a minifilter. All calls to a file object open by FltCreateX will be targeted to minifilters below yours.
So, there will be no reentrancy from top of the stack.
I guess that you have checked that the reference count really does go to
zero and that the cachmanager hasn’t appropriated it?
wrote in message news:xxxxx@ntfsd… > Hi Folks, > > I’ve got a minifilter driver that does some sort of file mirroring. > When I invoke FltClose, it sends IRP_MJ_CLEANUP below my minifilter, thus > bypassing my IRP_MJ_CLEANUP handler. I thought, however, IRP_MJ_CLOSE on > that file (when refcount drops to zero) still goes through the whole > filesystem stack from the top to the bottom so that I can see it in my > IRP_MJ_CLOSE handler. Surprisingly enough, my IRP_MJ_CLOSE handler never > sees it. Is that by design or am I missing something here? > > Any comment would be greatly appreciated. > > Regards, > Sean >
I guess that you have checked that the reference count really does go to
zero and that the cachmanager hasn’t appropriated it?
If the file has been opened by FltCreateFileX, then why should IRP_MJ_CLOSE
come from top of the stack on issuing FltClose?
I suppose both Cleanup and Close for that file object will be sent directly
to the minifilters below in the stack.
So, after the cache manager has released its reference from that file object
(and IRP_MJ_CLEANUP has already come before), the Close will be issued to
mini filters below, and you won’t be seeing the Close for that file object.
RE: [ntfsd] [Minifilter] Does FltClose force filter manager to send IRP_MJ_CLOSE below my filter?Ayush.
I guess my counter question is “Why *does* he see Cleanup?”
Also, consider the following:
FltCreate
ObReferenceFileObject
FltClose
//
// The CLEANUP happens now
//
ObDereferenceFileObject
//
// This is when we expect the close. But IoDeleteFileObject (or whatever it is called) almost certainly
// doesn’t know or care about FltMgr and altitudes - all it *can* do is to roll an IRMP_MJ_CLOSE and
// fire it down the stack.
//
“Ayush Gupta” wrote in message news:xxxxx@ntfsd… Hi Rod,
>I guess that you have checked that the reference count really does go to
>zero and that the cachmanager hasn’t appropriated it?
If the file has been opened by FltCreateFileX, then why should IRP_MJ_CLOSE come from top of the stack on issuing FltClose?
I suppose both Cleanup and Close for that file object will be sent directly to the minifilters below in the stack.
So, after the cache manager has released its reference from that file object (and IRP_MJ_CLEANUP has already come before), the Close will be issued to mini filters below, and you won’t be seeing the Close for that file object.
I guess my counter question is “Why *does* he see Cleanup?”
I think you misread his post. He said that the IRP_MJ_CLEANUP is sent
directly to the mini filter below his.
“When I invoke FltClose, it sends IRP_MJ_CLEANUP below my minifilter, thus
bypassing my IRP_MJ_CLEANUP handler”
This is when we expect the close. But IoDeleteFileObject (or whatever it
is called) almost certainly
doesn’t know or care about FltMgr and altitudes - all it *can* do is to
roll an IRMP_MJ_CLOSE and
fire it down the stack.
Well I haven’t exactly traced the call stack, but if you take the example of
IoCreateFileSpecifyDeviceObjectHint, then also all the operations on the
handle opened using this function are sent to filters below yours. This
means that Io Manager certainly knows the top device object to which an IRP
for a file object should be sent.
And I don’t know it exactly but this parsing is done in IopParseDevice by
calling IopCheckTopDeviceHint.