Is there any way to avoid delayed close(IRP_MJ_CLOSE). I mean close IRP will
be sent immediatly after all user handles are closed.
Is it possible. I thought of one way described below.
We recieve IRP_MJ_CLOSE IRP when the last reference to that file stream is
closed by cache manager. but for non buffered access there is no role of
cache manager so the IRP_MJ_CLOSE would be sent immediatly when the last
user handle is closed. Assuming no other component accept CM, increased the
reference count, so for avoiding delayed close(IRP_MJ_CLOSE), opeining the
file for non buffered access is sufficient.
> We recieve IRP_MJ_CLOSE IRP when the last reference to that file stream is
closed by cache manager. but for non buffered access there is no role of
cache manager so the IRP_MJ_CLOSE would be sent immediatly when the last
user handle is closed.
Although IRP_MJ_CLOSE *may* get sent right after a user closes the last open handle, there is no guarantee of it whatsoever. IRP_MJ_CLOSE gets sent only after reference count on the file object goes down to zero (please note that outstanding reference count >= number of open handles - some kernel-mode component may still keep an oustanding reference on the file object even if all handles to it are closed) and all outstanding I/O requests have been completed or canceled.
As you can see, you depend on factors that are just beyond your control…
Anton Bassov
Your solution will not work, let the group know why you want the CLOSE
immediately, and we can probably suggest an approach that will not force
the CLOSE but let you do what you want.
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply
“Tim Parker” wrote in message news:xxxxx@ntfsd…
> Is there any way to avoid delayed close(IRP_MJ_CLOSE). I mean close IRP
> will
> be sent immediatly after all user handles are closed.
> Is it possible. I thought of one way described below.
>
> We recieve IRP_MJ_CLOSE IRP when the last reference to that file stream
> is
> closed by cache manager. but for non buffered access there is no role of
> cache manager so the IRP_MJ_CLOSE would be sent immediatly when the last
> user handle is closed. Assuming no other component accept CM, increased
> the
> reference count, so for avoiding delayed close(IRP_MJ_CLOSE), opeining
> the
> file for non buffered access is sufficient.
>
Although IRP_MJ_CLOSE *may* get sent right after a user closes the last
open handle, there is no guarantee of it whatsoever. IRP_MJ_CLOSE gets sent
only after reference count on the file object goes down to zero (please note
that outstanding reference count >= number of open handles - some
kernel-mode component may still keep an oustanding reference on the file
object even if all handles to it are closed) and all outstanding I/O
requests have been completed or canceled.
As you can see, you depend on factors that are just beyond your control…
Anton Bassov
I think that even if we managed to somehow control IRP_MJ_CLOSE
invocations, the close code itself may decide to async or delay the close.
Sara
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@symantec.com To
unsubscribe send a blank email to xxxxx@lists.osr.com
> let the group know why you want the CLOSE
immediately, and we can probably suggest an approach that will not force
the CLOSE but let you do what you want.
Brilliant advice, Don - indeed, quite often it happens that people believe they need this or that feature, spend ages figuring out how to do it and whether it can be done at all… and then suddenly realize that it is just not needed, because exactly the same final objective can be achieved easily and in fully “supported” way. It happened to me more than once…
Anton Bassov