This is probably an faq, so apologies, but I’m a bit confused here. I
beileve I understand the IRP_MJ_CREATE/CLEANUP/CLOSE sequence, and that
there are write(s) between the cleanup and the close. The question is,
whether its possible for there to be write(s) after the close; or more
accurately after the number of close has become equal to the number of
create. Thanks in advance!
Well, this is certainly uniquely worded (and I’ve been answering questions
for a while).
There should only be a single IRP_MJ_CREATE for a given file object, just
like there should only be a single IRP_MJ_CLOSE for a given file object. Of
course, this really means “nested”. So you could get
IRP_MJ_CREATE/IRP_MJ_CLOSE and then the same file object back, but
representing a different file.
Or perhaps you are asking a more subtle question - like against the same
*file* rather than the same *file object*. There can be nested opens
against the same file. And if you are the file system, you will see
everything - all of the creates, all of the cleanups, and all of the closes.
Of course, the one who is “in the dark” here is the filter driver. The file
system can create its own file objects - and there’s no IRP_MJ_CREATE that
accompanies that. After all, why would that be necessary, given that the
FILE SYSTEM created it - and hence knows about this file object.
So if you try to count IRP_MJ_CREATE and IRP_MJ_CLEANUP and IRP_MJ_CLOSE
operations on a given *file* (across multiple file objects) what you will
observe is the relationship:
of IRP_MJ_CREATEs <= # of IRP_MJ_CLEANUP
and
of IRP_MJ_CREATEs <= # of IRP_MJ_CLOSE
Now it SHOULD be the case that:
of IRP_MJ_CLEANUP <= # of IRP_MJ_CLOSE
but it is possible (due to filters, actually) that you might see extra
cleanups (this happens when someone creates a handle to a file object AFTER
the initial IRP_MJ_CLEANUP. It shouldn’t happen, as it is a bug, but
interestingly enough the file systems appear to be resilient in the face of
such bugs.)
There is a discussion in the FAQ about reference counting files and it
discusses this issue in more detail. In essence, the algorithm is:
For each IRP_MJ_CREATE, increment the reference count by one.
For each IRP_MJ_CLOSE, decrement the reference count by one (if it is above
zero)
IF the reference count drops to zero the file is truly closed if and only
iff:
The FileObject->SectionObjectPointers->DataSectionObject == NULL AND
The FileObject->SectionObjectPointers->ImageSectionObject == NULL
If not, there are still outstanding references.
When the reference count is zero (or less than zero if you increment it
those etra times) and the section object pointers are gone, then the file is
truly and totally closed. The file system doesn’t know about it, the VM
doesn’t know about it and you can safely consider it closed.
Regards,
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com
-----Original Message-----
From: Lyndon J. Clarke [mailto:xxxxx@gcplc.com]
Sent: Tuesday, February 18, 2003 6:03 AM
To: File Systems Developers
Subject: [ntfsd] Write after Close?
This is probably an faq, so apologies, but I’m a bit confused here. I
beileve I understand the IRP_MJ_CREATE/CLEANUP/CLOSE sequence, and that
there are write(s) between the cleanup and the close. The question is,
whether its possible for there to be write(s) after the close; or more
accurately after the number of close has become equal to the number of
create. Thanks in advance!
You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
Ah, well, I do apologise for the wording. I am referring to the counts of
create, cleanup and close for the FCB as opposed to the FILE_OBJECT. So
the question is, whether or not, after the number of close for the FCB is
the same as the number of create for the FCB, can there be a page write?
Yes. That was the point of the balance of my original note.
Regards,
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com
-----Original Message-----
From: Lyndon J. Clarke [mailto:xxxxx@gcplc.com]
Sent: Tuesday, February 18, 2003 7:58 AM
To: File Systems Developers
Subject: [ntfsd] RE: Write after Close?
Ah, well, I do apologise for the wording. I am referring to the counts of
create, cleanup and close for the FCB as opposed to the FILE_OBJECT. So
the question is, whether or not, after the number of close for the FCB is
the same as the number of create for the FCB, can there be a page write?
You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
Ooops, I shouldda read your text more carefully. As it happens the filter
driver is using the “simple algorithm” for reference counts described in
the nt insider article. The bit I was confused about was, using this
algorithm, when #create - #close is zero, can there be a page write. On
re-reading the article, the answer looks like a pretty clear yes. And I
can see that we just crossed on the wire - thanks for the reply!
The next thing (oh dear always a next thing) is … the #create versus the
#cleanup. With the exception of the bug you mentioned, is #create-#cleanup
meaningful. I am trying to identify when all user handles for all file
objects for the file-as-in-fcb are closed. Thanks again!
User opens HAVE to show up as IRP_MJ_CREATE and their handle close shows up
as IRP_MJ_CLEANUP. Note that even if the user were to duplicate the handle
(or inherit it in a sub-process) there is only one IRP_MJ_CLEANUP.
Regards,
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com
-----Original Message-----
From: Lyndon J. Clarke [mailto:xxxxx@gcplc.com]
Sent: Tuesday, February 18, 2003 8:20 AM
To: File Systems Developers
Subject: [ntfsd] RE: Write after Close?
Ooops, I shouldda read your text more carefully. As it happens the filter
driver is using the “simple algorithm” for reference counts described in
the nt insider article. The bit I was confused about was, using this
algorithm, when #create - #close is zero, can there be a page write. On
re-reading the article, the answer looks like a pretty clear yes. And I
can see that we just crossed on the wire - thanks for the reply!
The next thing (oh dear always a next thing) is … the #create versus the
#cleanup. With the exception of the bug you mentioned, is #create-#cleanup
meaningful. I am trying to identify when all user handles for all file
objects for the file-as-in-fcb are closed. Thanks again!
You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
Hi Tony. So the question boiled down to whether or not there could be
IRP_MJ_CLEANUP at all other than for the user opened/created handles; e.g.
for the stream files. I think by tracking the file objects as well as the
fcb I can in fact sort this one out. Thanks again, Lyndon.
After the CLOSE, the file object is no more. CLOSE is like a C++
destructor.
Max
----- Original Message -----
From: “Lyndon J. Clarke”
To: “File Systems Developers”
Sent: Tuesday, February 18, 2003 2:03 PM
Subject: [ntfsd] Write after Close?
> This is probably an faq, so apologies, but I’m a bit confused here.
I
> beileve I understand the IRP_MJ_CREATE/CLEANUP/CLOSE sequence, and
that
> there are write(s) between the cleanup and the close. The question
is,
> whether its possible for there to be write(s) after the close; or
more
> accurately after the number of close has become equal to the number
of
> create. Thanks in advance!
>
> —
> You are currently subscribed to ntfsd as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
Hi Maxim. Thanks for the response. Its understood. It turns out I was just
confused with the stream file objects.