What is the difference between stream-context and stream-handle-context?

My minifilter traces a directory rename operation by setting stream-handle
context. It sets the context under the POST-CREATE, changes some data under
PRE-SETINFORMATION, and clear the context under PRE-CLEANUP.
But the thing is not so simple. Several CREATE and CLEANUP IRPs using the
same fileobject as the following sequence shows:

PostCreate Called, fileObj: 86a65720
PreCleanup Called, fileObj: 86a65720
PostCreate Called, Set StreamHandle Context, fileObj: 86a65720
PreCleanup Called, StreamHandle Context deleted, fileObj: 86a65720
PostCreate Called, fileObj: 86a65720
PreSetInformation, Get StreamHandle Context Failed, fileObj: 86a65720
PreCleanup Called, fileObj: 86a65720

So before the SETINFORMATION IRP uses the stream handle context, the context
is already cleared by another CLEANUP IRP.
Why is the same file object reused by multiple CREATE IRPs?
Should I use a CLOSE callback to clear the context?
Some old OSR threads say that a CLOSE IRP may not come for a long time.

Thanks for any comment.

Shangwu

Are you tracing CLOSE operations? If not I don’t see any problems with the
trace below - The IoManager is reusing the same address for three
(logically) different FileObjects. You are only ocassionally attaching
stream handle contexts and so you are only getting those contexts back.

Some old OSR threads say that a CLOSE IRP may not come for a long time.

Yes, but the close IRP may also (and usually does) come immediately,
particularly for directories.

Should I use a CLOSE callback to clear the context?
It depends whether you care about any operations which come after a cleanup,
but for directory rename I’d say you are safe with CLEANUP.

“Shangwu” wrote in message news:xxxxx@ntfsd…
> My minifilter traces a directory rename operation by setting stream-handle
> context. It sets the context under the POST-CREATE, changes some data
> under PRE-SETINFORMATION, and clear the context under PRE-CLEANUP.
> But the thing is not so simple. Several CREATE and CLEANUP IRPs using the
> same fileobject as the following sequence shows:
>
> PostCreate Called, fileObj: 86a65720
> PreCleanup Called, fileObj: 86a65720
> PostCreate Called, Set StreamHandle Context, fileObj: 86a65720
> PreCleanup Called, StreamHandle Context deleted, fileObj: 86a65720
> PostCreate Called, fileObj: 86a65720
> PreSetInformation, Get StreamHandle Context Failed, fileObj: 86a65720
> PreCleanup Called, fileObj: 86a65720
>
> So before the SETINFORMATION IRP uses the stream handle context, the
> context is already cleared by another CLEANUP IRP.
> Why is the same file object reused by multiple CREATE IRPs?
> Should I use a CLOSE callback to clear the context?
> Some old OSR threads say that a CLOSE IRP may not come for a long time.
>
> Thanks for any comment.
>
> Shangwu
>
>
>
>

Thanks Rod for your help.
I am tracing RENAME operations. I don’t understand that during a RENAME
transaction (from open, rename, cleanup, to close) the file object is reused
by another operation with open and cleanup.

Another question is that if I want to set a stream handle context for a file
object, how do I identify different handles for the referred file object?

Thanks,

Shangwu

“Rod Widdowson” wrote in message
news:xxxxx@ntfsd…
> Are you tracing CLOSE operations? If not I don’t see any problems with
> the trace below - The IoManager is reusing the same address for three
> (logically) different FileObjects. You are only ocassionally attaching
> stream handle contexts and so you are only getting those contexts back.
>
>> Some old OSR threads say that a CLOSE IRP may not come for a long time.
>
> Yes, but the close IRP may also (and usually does) come immediately,
> particularly for directories.
>
>> Should I use a CLOSE callback to clear the context?
> It depends whether you care about any operations which come after a
> cleanup, but for directory rename I’d say you are safe with CLEANUP.
>
> “Shangwu” wrote in message news:xxxxx@ntfsd…
>> My minifilter traces a directory rename operation by setting
>> stream-handle context. It sets the context under the POST-CREATE, changes
>> some data under PRE-SETINFORMATION, and clear the context under
>> PRE-CLEANUP.
>> But the thing is not so simple. Several CREATE and CLEANUP IRPs using the
>> same fileobject as the following sequence shows:
>>
>> PostCreate Called, fileObj: 86a65720
>> PreCleanup Called, fileObj: 86a65720
>> PostCreate Called, Set StreamHandle Context, fileObj: 86a65720
>> PreCleanup Called, StreamHandle Context deleted, fileObj: 86a65720
>> PostCreate Called, fileObj: 86a65720
>> PreSetInformation, Get StreamHandle Context Failed, fileObj: 86a65720
>> PreCleanup Called, fileObj: 86a65720
>>
>> So before the SETINFORMATION IRP uses the stream handle context, the
>> context is already cleared by another CLEANUP IRP.
>> Why is the same file object reused by multiple CREATE IRPs?
>> Should I use a CLOSE callback to clear the context?
>> Some old OSR threads say that a CLOSE IRP may not come for a long time.
>>
>> Thanks for any comment.
>>
>> Shangwu
>>
>>
>>
>>
>
>
>

I forget to mention that this is only happened for requests coming from SRV
process.

“Shangwu” wrote in message news:xxxxx@ntfsd…
> Thanks Rod for your help.
> I am tracing RENAME operations. I don’t understand that during a RENAME
> transaction (from open, rename, cleanup, to close) the file object is
> reused by another operation with open and cleanup.
>
> Another question is that if I want to set a stream handle context for a
> file object, how do I identify different handles for the referred file
> object?
>
> Thanks,
>
> Shangwu
>
>
> “Rod Widdowson” wrote in message
> news:xxxxx@ntfsd…
>> Are you tracing CLOSE operations? If not I don’t see any problems with
>> the trace below - The IoManager is reusing the same address for three
>> (logically) different FileObjects. You are only ocassionally attaching
>> stream handle contexts and so you are only getting those contexts back.
>>
>>> Some old OSR threads say that a CLOSE IRP may not come for a long time.
>>
>> Yes, but the close IRP may also (and usually does) come immediately,
>> particularly for directories.
>>
>>> Should I use a CLOSE callback to clear the context?
>> It depends whether you care about any operations which come after a
>> cleanup, but for directory rename I’d say you are safe with CLEANUP.
>>
>> “Shangwu” wrote in message news:xxxxx@ntfsd…
>>> My minifilter traces a directory rename operation by setting
>>> stream-handle context. It sets the context under the POST-CREATE,
>>> changes some data under PRE-SETINFORMATION, and clear the context under
>>> PRE-CLEANUP.
>>> But the thing is not so simple. Several CREATE and CLEANUP IRPs using
>>> the same fileobject as the following sequence shows:
>>>
>>> PostCreate Called, fileObj: 86a65720
>>> PreCleanup Called, fileObj: 86a65720
>>> PostCreate Called, Set StreamHandle Context, fileObj: 86a65720
>>> PreCleanup Called, StreamHandle Context deleted, fileObj: 86a65720
>>> PostCreate Called, fileObj: 86a65720
>>> PreSetInformation, Get StreamHandle Context Failed, fileObj: 86a65720
>>> PreCleanup Called, fileObj: 86a65720
>>>
>>> So before the SETINFORMATION IRP uses the stream handle context, the
>>> context is already cleared by another CLEANUP IRP.
>>> Why is the same file object reused by multiple CREATE IRPs?
>>> Should I use a CLOSE callback to clear the context?
>>> Some old OSR threads say that a CLOSE IRP may not come for a long time.
>>>
>>> Thanks for any comment.
>>>
>>> Shangwu
>>>
>>>
>>>
>>>
>>
>>
>>
>
>
>

> I don’t understand that during a RENAME transaction (from open, rename,

cleanup, to close) the file object is reused by another operation with
open and cleanup.

Which is why I asked originally whether you are tracing close? If not all I
am seeing in your original; post is

CREATE, CLEANUP, [CLOSE not traced]
CREATE, [sethandle], CLEANUP, [CLOSE not traced]
CREATE, SET_INFORMATION, CLEANUP, [CLOSE not traced]

So you are getting three *different* file objects at the same address.

Yes. The same file object is reused for many times during a RENAME
operation.

“Rod Widdowson” wrote in message
news:xxxxx@ntfsd…
>> I don’t understand that during a RENAME transaction (from open, rename,
>> cleanup, to close) the file object is reused by another operation with
>> open and cleanup.
>
> Which is why I asked originally whether you are tracing close? If not all
> I am seeing in your original; post is
>
> CREATE, CLEANUP, [CLOSE not traced]
> CREATE, [sethandle], CLEANUP, [CLOSE not traced]
> CREATE, SET_INFORMATION, CLEANUP, [CLOSE not traced]
>
> So you are getting three different file objects at the same address.
>
>
>
>
>
>

Because the Memory Manager can cache the file object and use it for other applications performing mapped I/O, whenever a Cleanup operation is seen on a file object, that file object stream should no longer be considered unique.

The last post to this thread was 13 years ago…If you have a question post to a new thread.