I am new to minifilter development. How can I figure out that last
handle to a particular file got closed meaning there is no open handle
to the file by any application?
I think of a solution, I track create and close operations in mini
filter. I will maintain a list of files along with the processes that
opened the file. Once all the processes which opened the handle for
the file closes the file, can I assume that there is no handle open on
the file currently?
Irp-mj-cleanup is called by i/o manager when the last outstanding handle for a file was closed.
No so … IRM_MJ_CLEANUP will be sent when the last handle for a FILE_OBJECT
is closed.
This is quite different to the “last handle for a file” since of course
there can be, and often are, multiple FILE_OBJECT for the same file.
If you want to know if you receive the last IRP_MJ_CLEANUP for a file, in
other words IRP_MJ_CLEANUP for the last remaining FILE_OBJECT for the file,
you have no choice but to count file objects.
wrote in message news:xxxxx@ntfsd…
> Irp-mj-cleanup is called by i/o manager when the last outstanding handle
> for a file was closed.
>
that is correct I misunderstood the question.
Thanks for replying
On 8/10/08, Lyndon J Clarke wrote:
> No so … IRM_MJ_CLEANUP will be sent when the last handle for a FILE_OBJECT
> is closed.
>
> This is quite different to the “last handle for a file” since of course
> there can be, and often are, multiple FILE_OBJECT for the same file.
>
> If you want to know if you receive the last IRP_MJ_CLEANUP for a file, in
> other words IRP_MJ_CLEANUP for the last remaining FILE_OBJECT for the file,
> you have no choice but to count file objects.
>
> wrote in message news:xxxxx@ntfsd…
>> Irp-mj-cleanup is called by i/o manager when the last outstanding handle
>> for a file was closed.
>>
>
>
>
> —
> NTFSD is sponsored by OSR
>
> For our schedule debugging and file system seminars
> (including our new fs mini-filter seminar) visit:
> http://www.osr.com/seminars
>
> You are currently subscribed to ntfsd as: xxxxx@gmail.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
Out of curiousity, what happens if someone calls ObOpenObjectByPointer to open a new HANDLE after IRP_MJ_CLEANUP?
-----Original Message-----
From: Lyndon J Clarke
Sent: Sunday, August 10, 2008 11:23
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] How to detect last handle getting closed for a particular file ?
No so … IRM_MJ_CLEANUP will be sent when the last handle for a FILE_OBJECT
is closed.
This is quite different to the “last handle for a file” since of course
there can be, and often are, multiple FILE_OBJECT for the same file.
If you want to know if you receive the last IRP_MJ_CLEANUP for a file, in
other words IRP_MJ_CLEANUP for the last remaining FILE_OBJECT for the file,
you have no choice but to count file objects.
wrote in message news:xxxxx@ntfsd…
> Irp-mj-cleanup is called by i/o manager when the last outstanding handle
> for a file was closed.
>
—
NTFSD is sponsored by OSR
For our schedule debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars
You are currently subscribed to ntfsd as: xxxxx@valhallalegends.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
Gross…I’d hope that Ob would fail the operation as I’m not sure what you’d
do with the handle that you got back (the file object would have
FO_CLEANUP_COMPLETE set, making it slightly less than useful).
-scott
–
Scott Noone
Software Engineer
OSR Open Systems Resources, Inc.
http://www.osronline.com
“Skywing” wrote in message news:xxxxx@ntfsd…
Out of curiousity, what happens if someone calls ObOpenObjectByPointer to
open a new HANDLE after IRP_MJ_CLEANUP?
- S
-----Original Message-----
From: Lyndon J Clarke
Sent: Sunday, August 10, 2008 11:23
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] How to detect last handle getting closed for a
particular file ?
No so … IRM_MJ_CLEANUP will be sent when the last handle for a FILE_OBJECT
is closed.
This is quite different to the “last handle for a file” since of course
there can be, and often are, multiple FILE_OBJECT for the same file.
If you want to know if you receive the last IRP_MJ_CLEANUP for a file, in
other words IRP_MJ_CLEANUP for the last remaining FILE_OBJECT for the file,
you have no choice but to count file objects.
wrote in message news:xxxxx@ntfsd…
> Irp-mj-cleanup is called by i/o manager when the last outstanding handle
> for a file was closed.
>
—
NTFSD is sponsored by OSR
For our schedule debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars
You are currently subscribed to ntfsd as: xxxxx@valhallalegends.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
What a fascinating question! The related question, perhaps another great
question in filter interop, is what happens if a lower filter calls
ObOpenObjectByPointer, *before* the file system processes the IRP_MJ_CLEANUP
… blech!
“Skywing” wrote in message news:xxxxx@ntfsd…
Out of curiousity, what happens if someone calls ObOpenObjectByPointer to
open a new HANDLE after IRP_MJ_CLEANUP?
- S
-----Original Message-----
From: Lyndon J Clarke
Sent: Sunday, August 10, 2008 11:23
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] How to detect last handle getting closed for a
particular file ?
No so … IRM_MJ_CLEANUP will be sent when the last handle for a FILE_OBJECT
is closed.
This is quite different to the “last handle for a file” since of course
there can be, and often are, multiple FILE_OBJECT for the same file.
If you want to know if you receive the last IRP_MJ_CLEANUP for a file, in
other words IRP_MJ_CLEANUP for the last remaining FILE_OBJECT for the file,
you have no choice but to count file objects.
wrote in message news:xxxxx@ntfsd…
> Irp-mj-cleanup is called by i/o manager when the last outstanding handle
> for a file was closed.
>
—
NTFSD is sponsored by OSR
For our schedule debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars
You are currently subscribed to ntfsd as: xxxxx@valhallalegends.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
Well, first let’s see what happens when a handles get closed. I/O manager
has an internal routine called IopCloseFile(), that has very little logical
steps involved:
Now comments on the ObOpenObjectbyPointer:
" If the Object parameter points to a file object (that is, a FILE_OBJECT
structure), ObOpenObjectByPointer can only be called after at least one
handle has been created for the file object. Callers can check the Flags
member of the FILE_OBJECT structure that the Object parameter points to. If
the FO_HANDLE_CREATED flag is set, this means that one or more handles have
been created for the file object, so it is safe to call
ObOpenObjectByPointer. "
Now your questions becomes pointless because IRP_MJ_CLEANUP being closed you
call to ObOpenObjectByPointer is not “safe to call” .
Now according to the logical steps involved in a cleanup request, and
knowing that the object manager has the ObCreateObjectType routine, the
Object Manager is “aware” of what object you are trying to re-create a
handle after it’s last handle was closed, to some you may be granted, the
access, to some no. Be aware the IRP_MJ_CLEANUP is only for file objects.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Lyndon J Clarke
Sent: Tuesday, August 12, 2008 11:04 PM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] Re:How to detect last handle getting closed for a
particular file ?
What a fascinating question! The related question, perhaps another great
question in filter interop, is what happens if a lower filter calls
ObOpenObjectByPointer, *before* the file system processes the IRP_MJ_CLEANUP
… blech!
“Skywing” wrote in message news:xxxxx@ntfsd…
Out of curiousity, what happens if someone calls ObOpenObjectByPointer to
open a new HANDLE after IRP_MJ_CLEANUP?
- S
-----Original Message-----
From: Lyndon J Clarke
Sent: Sunday, August 10, 2008 11:23
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] How to detect last handle getting closed for a
particular file ?
No so … IRM_MJ_CLEANUP will be sent when the last handle for a FILE_OBJECT
is closed.
This is quite different to the “last handle for a file” since of course
there can be, and often are, multiple FILE_OBJECT for the same file.
If you want to know if you receive the last IRP_MJ_CLEANUP for a file, in
other words IRP_MJ_CLEANUP for the last remaining FILE_OBJECT for the file,
you have no choice but to count file objects.
wrote in message news:xxxxx@ntfsd…
> Irp-mj-cleanup is called by i/o manager when the last outstanding handle
> for a file was closed.
>
—
NTFSD is sponsored by OSR
For our schedule debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars
You are currently subscribed to ntfsd as: xxxxx@valhallalegends.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
NTFSD is sponsored by OSR
For our schedule debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars
You are currently subscribed to ntfsd as: xxxxx@gmail.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
>Out of curiousity, what happens if someone calls ObOpenObjectByPointer to open
a new HANDLE after IRP_MJ_CLEANUP?
Will fail due to FO_CLEANUP_COMPLETE set in the file object.
–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
That seems somewhat fishy to me. What happens when the last handle is closed between when FO_HANDLE_CREATED is tested and ObOpenObjectByPointer is called?
Incidentally, and curiously enough, it seems that IopCloseFile *sets* FO_HANDLE_CREATED before sending IRP_MJ_CLEANUP on down. (Though, one would expect that this flag should have already been set to ever get into IopCloseFile in the first place.)
The fact that this is done leads me to believe that FO_HANDLE_CREATED isn’t magically unset after the fact, as it certainly won’t be unset down the IRP_MJ_CLEANUP path. This begs the question of how you are supposed to synchronize with cleanup processing with respect to calling ObOpenObjectByPointer on PFILE_OBJECTs.
Then again, perhaps the close routine is synchronized with new handle creation. Not sure that really helps you though, as there is still the problem of you having a PFILE_OBJECT that you stashed away somewhere, which then gets the last handle closed, and there not being a particularly great way to synchronize with that happening to ensure that you never call into ObOpenObjectByPointer with a PFILE_OBJECT that already has undergone cleanup. To safely handle that case, you would need to synchronize with the object manager close callout.
I’ll have to see about poking at this in a test driver. It seems that to work safely (if safely -> not allow a handle to be reopened once IopCloseFile is invoked), though, that IopCloseFile must be synchronized with handle creation for PFILE_OBJECTs, and that it must test for IopCloseFile having already been entered.
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Bercea Gabriel
Sent: Tuesday, August 12, 2008 7:43 PM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] Re:How to detect last handle getting closed for a particular file ?
Well, first let’s see what happens when a handles get closed. I/O manager
has an internal routine called IopCloseFile(), that has very little logical
steps involved:
Now comments on the ObOpenObjectbyPointer:
" If the Object parameter points to a file object (that is, a FILE_OBJECT
structure), ObOpenObjectByPointer can only be called after at least one
handle has been created for the file object. Callers can check the Flags
member of the FILE_OBJECT structure that the Object parameter points to. If
the FO_HANDLE_CREATED flag is set, this means that one or more handles have
been created for the file object, so it is safe to call
ObOpenObjectByPointer. "
Now your questions becomes pointless because IRP_MJ_CLEANUP being closed you
call to ObOpenObjectByPointer is not “safe to call” .
Now according to the logical steps involved in a cleanup request, and
knowing that the object manager has the ObCreateObjectType routine, the
Object Manager is “aware” of what object you are trying to re-create a
handle after it’s last handle was closed, to some you may be granted, the
access, to some no. Be aware the IRP_MJ_CLEANUP is only for file objects.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Lyndon J Clarke
Sent: Tuesday, August 12, 2008 11:04 PM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] Re:How to detect last handle getting closed for a
particular file ?
What a fascinating question! The related question, perhaps another great
question in filter interop, is what happens if a lower filter calls
ObOpenObjectByPointer, *before* the file system processes the IRP_MJ_CLEANUP
… blech!
“Skywing” wrote in message news:xxxxx@ntfsd…
Out of curiousity, what happens if someone calls ObOpenObjectByPointer to
open a new HANDLE after IRP_MJ_CLEANUP?
- S
-----Original Message-----
From: Lyndon J Clarke
Sent: Sunday, August 10, 2008 11:23
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] How to detect last handle getting closed for a
particular file ?
No so … IRM_MJ_CLEANUP will be sent when the last handle for a FILE_OBJECT
is closed.
This is quite different to the “last handle for a file” since of course
there can be, and often are, multiple FILE_OBJECT for the same file.
If you want to know if you receive the last IRP_MJ_CLEANUP for a file, in
other words IRP_MJ_CLEANUP for the last remaining FILE_OBJECT for the file,
you have no choice but to count file objects.
wrote in message news:xxxxx@ntfsd…
> Irp-mj-cleanup is called by i/o manager when the last outstanding handle
> for a file was closed.
>
—
NTFSD is sponsored by OSR
For our schedule debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars
You are currently subscribed to ntfsd as: xxxxx@valhallalegends.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
NTFSD is sponsored by OSR
For our schedule debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars
You are currently subscribed to ntfsd as: xxxxx@gmail.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
NTFSD is sponsored by OSR
For our schedule debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars
You are currently subscribed to ntfsd as: xxxxx@valhallalegends.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
>
That seems somewhat fishy to me. What happens when the last handle is
closed between when FO_HANDLE_CREATED >is tested and ObOpenObjectByPointer
is called?
There is nothing fishy, if the OBJECT is a FILE_OBJECT, they functions have
to acquire the MainResource exclusively. Which one acquires it is the
winner.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Skywing
Sent: Wednesday, August 13, 2008 3:41 AM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] Re:How to detect last handle getting closed for a
particular file ?
That seems somewhat fishy to me. What happens when the last handle is
closed between when FO_HANDLE_CREATED is tested and ObOpenObjectByPointer is
called?
Incidentally, and curiously enough, it seems that IopCloseFile *sets*
FO_HANDLE_CREATED before sending IRP_MJ_CLEANUP on down. (Though, one would
expect that this flag should have already been set to ever get into
IopCloseFile in the first place.)
The fact that this is done leads me to believe that FO_HANDLE_CREATED isn’t
magically unset after the fact, as it certainly won’t be unset down the
IRP_MJ_CLEANUP path. This begs the question of how you are supposed to
synchronize with cleanup processing with respect to calling
ObOpenObjectByPointer on PFILE_OBJECTs.
Then again, perhaps the close routine is synchronized with new handle
creation. Not sure that really helps you though, as there is still the
problem of you having a PFILE_OBJECT that you stashed away somewhere, which
then gets the last handle closed, and there not being a particularly great
way to synchronize with that happening to ensure that you never call into
ObOpenObjectByPointer with a PFILE_OBJECT that already has undergone
cleanup. To safely handle that case, you would need to synchronize with the
object manager close callout.
I’ll have to see about poking at this in a test driver. It seems that to
work safely (if safely -> not allow a handle to be reopened once
IopCloseFile is invoked), though, that IopCloseFile must be synchronized
with handle creation for PFILE_OBJECTs, and that it must test for
IopCloseFile having already been entered.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Bercea Gabriel
Sent: Tuesday, August 12, 2008 7:43 PM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] Re:How to detect last handle getting closed for a
particular file ?
Well, first let’s see what happens when a handles get closed. I/O manager
has an internal routine called IopCloseFile(), that has very little logical
steps involved:
Now comments on the ObOpenObjectbyPointer:
" If the Object parameter points to a file object (that is, a FILE_OBJECT
structure), ObOpenObjectByPointer can only be called after at least one
handle has been created for the file object. Callers can check the Flags
member of the FILE_OBJECT structure that the Object parameter points to. If
the FO_HANDLE_CREATED flag is set, this means that one or more handles have
been created for the file object, so it is safe to call
ObOpenObjectByPointer. "
Now your questions becomes pointless because IRP_MJ_CLEANUP being closed you
call to ObOpenObjectByPointer is not “safe to call” .
Now according to the logical steps involved in a cleanup request, and
knowing that the object manager has the ObCreateObjectType routine, the
Object Manager is “aware” of what object you are trying to re-create a
handle after it’s last handle was closed, to some you may be granted, the
access, to some no. Be aware the IRP_MJ_CLEANUP is only for file objects.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Lyndon J Clarke
Sent: Tuesday, August 12, 2008 11:04 PM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] Re:How to detect last handle getting closed for a
particular file ?
What a fascinating question! The related question, perhaps another great
question in filter interop, is what happens if a lower filter calls
ObOpenObjectByPointer, *before* the file system processes the IRP_MJ_CLEANUP
… blech!
“Skywing” wrote in message news:xxxxx@ntfsd…
Out of curiousity, what happens if someone calls ObOpenObjectByPointer to
open a new HANDLE after IRP_MJ_CLEANUP?
- S
-----Original Message-----
From: Lyndon J Clarke
Sent: Sunday, August 10, 2008 11:23
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] How to detect last handle getting closed for a
particular file ?
No so … IRM_MJ_CLEANUP will be sent when the last handle for a FILE_OBJECT
is closed.
This is quite different to the “last handle for a file” since of course
there can be, and often are, multiple FILE_OBJECT for the same file.
If you want to know if you receive the last IRP_MJ_CLEANUP for a file, in
other words IRP_MJ_CLEANUP for the last remaining FILE_OBJECT for the file,
you have no choice but to count file objects.
wrote in message news:xxxxx@ntfsd…
> Irp-mj-cleanup is called by i/o manager when the last outstanding handle
> for a file was closed.
>
—
NTFSD is sponsored by OSR
For our schedule debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars
You are currently subscribed to ntfsd as: xxxxx@valhallalegends.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
NTFSD is sponsored by OSR
For our schedule debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars
You are currently subscribed to ntfsd as: xxxxx@gmail.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
NTFSD is sponsored by OSR
For our schedule debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars
You are currently subscribed to ntfsd as: xxxxx@valhallalegends.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
NTFSD is sponsored by OSR
For our schedule debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars
You are currently subscribed to ntfsd as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
> There is nothing fishy, if the OBJECT is a FILE_OBJECT, they functions have
to acquire the MainResource exclusively.
I have major doubts Ob is ever aware of MainResource.
–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
Ob ofcourse not, but what involves creating a handle for a file, is more
than Ob, is Io.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Maxim S. Shatskih
Sent: Wednesday, August 13, 2008 3:21 PM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] Re:How to detect last handle getting closed for a
particular file ?
There is nothing fishy, if the OBJECT is a FILE_OBJECT, they functions
have
to acquire the MainResource exclusively.
I have major doubts Ob is ever aware of MainResource.
–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
NTFSD is sponsored by OSR
For our schedule debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars
You are currently subscribed to ntfsd as: xxxxx@gmail.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
The I/O Manager does not know anything about the internal structures
maintained by the file system. Some FsRtl routines do assume a specific
format for FsContext but even THEY do not assume there will be a “main
resource” because its existence is entirely optional.
Once IRP_MJ_CLEANUP is issued, there is no safe way for *any* driver
(other than the file system) to bump the reference count on a file
object (which includes opening it by pointer.) One of the more
interesting issues I had to help track down years ago was when a filter
on top of one of my file systems was doing ObReferenceObject (in
IRP_MJ_CLEANUP) and then they would call ObDereferenceObject. Since
IRP_MJ_CLEANUP had already been sent, the file object destructor
function sent IRP_MJ_CLOSE down. The filter passed that through, the
file system got the close, deleted the data structures and returned.
The filter’s code then returned from ObDereferenceObject and send the
IRP_MJ_CLEANUP (for the same file object) down to the file system
driver.
Real file systems must deal with cleanup/close interactions already (we
do things in IRP_MJ_CLEANUP that really can trigger IRP_MJ_CLOSE before
we’ve finished cleanup.) But *only* the file system can do that
correctly.
Indeed, there’s now a test in verifier that asserts you never bump the
reference count on the file object if it is already zero in order to
catch such cases. I would expect it to catch exactly the case
originally described.
Please do not assume you know how all file systems work based upon study
of one file system because you will be wrong.
Tony
OSR
That seems strange to me, as there seem to be ObDereferenceObject calls for the PFILE_OBJECT in IopCloseFile after IRP_MJ_CLEANUP is sent. I would not expect there to be zero object references when entering IRP_MJ_CLEANUP. Zero handle references, sure, though.
(Apologies if I misread IopCloseFile.)
-----Original Message-----
From: Tony Mason
Sent: Wednesday, August 13, 2008 09:36
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] Re:How to detect last handle getting closed for a particular file ?
The I/O Manager does not know anything about the internal structures
maintained by the file system. Some FsRtl routines do assume a specific
format for FsContext but even THEY do not assume there will be a “main
resource” because its existence is entirely optional.
Once IRP_MJ_CLEANUP is issued, there is no safe way for any driver
(other than the file system) to bump the reference count on a file
object (which includes opening it by pointer.) One of the more
interesting issues I had to help track down years ago was when a filter
on top of one of my file systems was doing ObReferenceObject (in
IRP_MJ_CLEANUP) and then they would call ObDereferenceObject. Since
IRP_MJ_CLEANUP had already been sent, the file object destructor
function sent IRP_MJ_CLOSE down. The filter passed that through, the
file system got the close, deleted the data structures and returned.
The filter’s code then returned from ObDereferenceObject and send the
IRP_MJ_CLEANUP (for the same file object) down to the file system
driver.
Real file systems must deal with cleanup/close interactions already (we
do things in IRP_MJ_CLEANUP that really can trigger IRP_MJ_CLOSE before
we’ve finished cleanup.) But only the file system can do that
correctly.
Indeed, there’s now a test in verifier that asserts you never bump the
reference count on the file object if it is already zero in order to
catch such cases. I would expect it to catch exactly the case
originally described.
Please do not assume you know how all file systems work based upon study
of one file system because you will be wrong.
Tony
OSR
—
NTFSD is sponsored by OSR
For our schedule debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars
You are currently subscribed to ntfsd as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
I also have doubts ObOpenObjectByPointer will call to Io for a file object.
Also note that most file objects have no FCBs and thus MainResource. Only
the FSD’s file objects are such, not the driver’s or socket’s or pipe’s file
objects.
MainResource is not mandatory at all, so, pulling the knowledge of its
existence to Ob would be the major OS misarchitecture from MS’s side, and I
expect them to be smart enough to never do such things.
–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
“Bercea Gabriel” wrote in message news:xxxxx@ntfsd…
> Ob ofcourse not, but what involves creating a handle for a file, is more
> than Ob, is Io.
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Maxim S. Shatskih
> Sent: Wednesday, August 13, 2008 3:21 PM
> To: Windows File Systems Devs Interest List
> Subject: Re:[ntfsd] Re:How to detect last handle getting closed for a
> particular file ?
>
> > There is nothing fishy, if the OBJECT is a FILE_OBJECT, they functions
> have
> > to acquire the MainResource exclusively.
>
> I have major doubts Ob is ever aware of MainResource.
>
> –
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> xxxxx@storagecraft.com
> http://www.storagecraft.com
>
>
> —
> NTFSD is sponsored by OSR
>
> For our schedule debugging and file system seminars
> (including our new fs mini-filter seminar) visit:
> http://www.osr.com/seminars
>
> You are currently subscribed to ntfsd as: xxxxx@gmail.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
There are only a few sources of references in the system typically:
The case in which Mm and Cc are using other file objects for the file,
you will see IRP_MJ_CLEANUP called with a file object that has a zero
reference count.
If the last reference is from Mm (or Cc) calls into them can trigger the
1->0 transition and that triggers the IRP_MJ_CLOSE.
Of course, I’m describing this based upon observations at the file
systems level, not based upon a reading of the destructor function.
Based upon your observation, I did a quick check and I believe you’ll
find that the dereferences there are not to the file object. Of course,
the specific behavior can also vary on a per OS version basis as well.
Finally, I’ll note I said “typically” because other parts of the OS can
keep references on the file object as well and this will change the
behavior.
Tony
OSR