Folks,
thanks
AP
>> If an IRP_MJ_CLOSE is sent on an FO which has outstanding Handle counts
> or reference counts, how does th file system respond?
Do you mean by explicitly building close IRP and doing IoCallDriver ?
> In the case where the FO has zero ref counts and handle counts, is
> IRP_MJ_CLOSE and IRP_MJ_CLEANUP sent automatically by the Object manager, or
> does the creater of this FO need to keep track of the same?
automatically by the Object manager. IO manager keeps track of the handle count and reference count and calls IRP_MJ_CLEANUP on becoming handle count = 0 and IRP_MJ_CLOSE on becoming reference count = 0
yes exclusively creating the irp and doing IoCalldriver
On Thu, Jan 14, 2010 at 7:04 PM, wrote:
> >> If an IRP_MJ_CLOSE is sent on an FO which has outstanding Handle counts
> >> or reference counts, how does th file system respond?
>
> Do you mean by explicitly building close IRP and doing IoCallDriver ?
>
> >> In the case where the FO has zero ref counts and handle counts, is
> >> IRP_MJ_CLOSE and IRP_MJ_CLEANUP sent automatically by the Object
> manager, or
> >> does the creater of this FO need to keep track of the same?
>
> automatically by the Object manager. IO manager keeps track of the handle
> count and reference count and calls IRP_MJ_CLEANUP on becoming handle count
> = 0 and IRP_MJ_CLOSE on becoming reference count = 0
>
> —
> NTFSD is sponsored by OSR
>
> For our schedule of debugging and file system seminars
> (including our new fs mini-filter seminar) visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
Correcting a bit …
Object manager keeps track of the handle count and reference counts.
IO manager sends IRP_MJ_CLEANUP request on becoming handle count = 0 and IRP_MJ_CLOSE request on becoming reference count = 0 of the FO.
The FO is maintained by the ObjMgr, so the ObjMgr should call IOmanager Iop*
routine which will eventually find the function handler for the top of the
stack of drivers handling MRJ_MJ_CLOSE/CLEANUP for that kind of obj (in this
case file) and call it, right?
On Thu, Jan 14, 2010 at 7:39 PM, wrote:
> Correcting a bit …
> Object manager keeps track of the handle count and reference counts.
> IO manager sends IRP_MJ_CLEANUP request on becoming handle count = 0 and
> IRP_MJ_CLOSE request on becoming reference count = 0 of the FO.
>
> —
> NTFSD is sponsored by OSR
>
> For our schedule of debugging and file system seminars
> (including our new fs mini-filter seminar) visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
Right
> If an IRP_MJ_CLOSE is sent on an FO which has outstanding Handle counts
> or reference counts, how does th file system respond ?
I believe file system is unaware of handle and reference counts on the file object. It assumes when IRP_MJ_CLEANUP gets called on handle count = 0 and IRP_MJ_CLOSE gets called on reference count and handle count are 0.
> yes exclusively creating the irp and doing IoCalldriver
I believe it will process IRP_MJ_CLOSE as usual deleting CCB unconditionally and FCB if it is last close. But the file object will be there as reference count has not got decremented and may result in crash when FsContext or FsContext2 is accessed or unexpected behavior.
If you want to cancel the open in the post create look at FltCancelFileOpen.
You should not be generating your own close IRP.
Bill Wandel
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Thursday, January 14, 2010 9:56 AM
To: Windows File Systems Devs Interest List
Subject: RE:[ntfsd] Close operation
Right
> If an IRP_MJ_CLOSE is sent on an FO which has outstanding Handle
> counts or reference counts, how does th file system respond ?
I believe file system is unaware of handle and reference counts on the file
object. It assumes when IRP_MJ_CLEANUP gets called on handle count = 0 and
IRP_MJ_CLOSE gets called on reference count and handle count are 0.
> yes exclusively creating the irp and doing IoCalldriver
I believe it will process IRP_MJ_CLOSE as usual deleting CCB unconditionally
and FCB if it is last close. But the file object will be there as reference
count has not got decremented and may result in crash when FsContext or
FsContext2 is accessed or unexpected behavior.
NTFSD is sponsored by OSR
For our schedule of debugging and file system seminars (including our new fs
mini-filter seminar) visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
>1. If an IRP_MJ_CLOSE is sent on an FO which has outstanding Handle counts or reference counts,
how does th file system respond? Does it fail teh IRP or does if forcefully close the FO
It cannot be sent.
MJ_CLOSE is like a C++ destructor - is sent immediately before FILE_OBJECT is deallocated.
- In the case where the FO has zero ref counts and handle counts, is IRP_MJ_CLOSE and
IRP_MJ_CLEANUP sent automatically by the Object manager
Yes. They are sent by Ob only.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
>yes exclusively creating the irp and doing IoCalldriver
I think it is explicitly banned in the docs. Only Ob must send them.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
>The FO is maintained by the ObjMgr, so the ObjMgr should call IOmanager Iop* routine which will
eventually find the function handler for the top of the stack of drivers handling
MRJ_MJ_CLOSE/CLEANUP for that kind of obj (in this case file) and call it, right?
Yes.
IopCloseFile and IopDeleteFile are registered as Ob’s close and delete handlers.
They assemble the IRP and send it down the stack.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com