But the problem that’s been found is that other filter drivers may do
something to initialize the cache (like a non-cached read/write) even
for a simple open/close.
Alexey Logachyov wrote:
>Imagine we use your scenario, but that second IRP is for a query
information
>call. In that case, the I/O Manager allocates the file object on the
stack.
>Since this is the FIRST file object to be used for I/O, it backs the
section
>object. That leads to horrible problems because it is not a REAL file
>object, but has now been used to back the section object.
>So, I argue that your model is defective on the surface because it
wouldn’t
>work without reference counting. Thus, I don’t think we need to make an
>already defective model work.
If the file object is only opened and closed immediately (for example to
determine whether file exists or not, or whether this is a directory) or
only used for some query info requests, caching will not be initialized,
then it means that Cc will not hold any reference to the file object, then
it means that this scenario may work.
-htfv
–
Nick Ryan (MVP for DDK)
There is no ‘you’ here. ANY filter in the stack can cause Mm or Cc to
grab a reference to the file object by performing side requests using
the file object. The only way to guard against this by derefencing the
file object using ObDereferenceObject (not by throwing down a close),
and in addition to only use a stream file object allocated by the filter
itself, not the file object in the stack.
Alexey Logachyov wrote:
Right, the problem was found. But this is the problem when you initialize
caching. If don’t intialize cache you may implement your code as usual. This
thread is not about it. The original poster described scenario when passing
IRP_MJ_CREATE IRP to lower driver may cause receiving recursive IRP_MJ_CLOSE
IRP (as I believed), which is quite possible.
-htfv
----- Original Message -----
From: “Nick Ryan”
> Newsgroups: ntfsd
> To: “File Systems Developers”
> Sent: Saturday, August 30, 2003 8:31 PM
> Subject: [ntfsd] Re: Tony,please.Question about Reference Counting art icle
> in NT Insider?
>
>
>
>>But the problem that’s been found is that other filter drivers may do
>>something to initialize the cache (like a non-cached read/write) even
>>for a simple open/close.
>>
>>Alexey Logachyov wrote:
>>
>>
>>>>Imagine we use your scenario, but that second IRP is for a query
>>>
>>>information
>>>
>>>
>>>>call. In that case, the I/O Manager allocates the file object on the
>>>
>>>stack.
>>>
>>>
>>>>Since this is the FIRST file object to be used for I/O, it backs the
>>>
>>>section
>>>
>>>
>>>>object. That leads to horrible problems because it is not a REAL file
>>>>object, but has now been used to back the section object.
>>>
>>>
>>>>So, I argue that your model is defective on the surface because it
>>>
>>>wouldn’t
>>>
>>>
>>>>work without reference counting. Thus, I don’t think we need to make an
>>>>already defective model work.
>>>
>>>
>>>If the file object is only opened and closed immediately (for example to
>>>determine whether file exists or not, or whether this is a directory) or
>>>only used for some query info requests, caching will not be initialized,
>>>then it means that Cc will not hold any reference to the file object,
>
> then
>
>>>it means that this scenario may work.
>>>
>>>-htfv
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>–
>>Nick Ryan (MVP for DDK)
>>
>>
>>—
>>You are currently subscribed to ntfsd as: xxxxx@vba.com.by
>>To unsubscribe send a blank email to xxxxx@lists.osr.com
>>
>>
>
>
>
>
>
>
–
Nick Ryan (MVP for DDK)