Context Management Question

Hi All,

I am still struggling with Context Management. I have read the article
“Tracking State and Context - Reference Counting for File System Filter
Drivers” on the OSR web site. I also combined the ctx and minispy sample to
create a sample driver that detects file changes. I am still a bit lost
though on the context management. I am trying to set a few flags in an
operation, then check for those flags in the close (on the same stream
object). I have some sample output below from a save of a word document. I
thought the following strategy useful for word: in PreWrite check for
IRP_NOCACHE and set flag. If in rename this flag is set it’s not a straight
rename but a word (or powerpoint or other ) save that uses renaming rather
than straight writes. In the below output, the IRP_NOCACHE is set on the
streamobject with address 0xE2E96440. When I check the rename on that same
address the flag is no longer set and the create count is 0 again. So do I
still need to use FsRtlInsertPerStreamContext and
FsRtlRemovePerStreamContext and the suggested algorithms in the article? Is
this because streams are different even though they have the same address
(address is being reused?) and I really need to just use the per-file
context?

Thanks, bjorn

PS: Here’s the sample output with IRP, Counters, Flags set, stream object
address and filename.

IRP_MJ_CLOSE Create: ‘2’ Cleanup:
‘1’ Close: ‘1’ File Create! SO: ‘E2E96440’ File is
‘\Device\HarddiskVolume2\testdir~WRD0000.tmp’
IRP_MJ_CLOSE Create: ‘9’ Cleanup:
‘9’ Close: ‘8’ NOCACHE WRITE!! SO: ‘E2E96440’ File is
‘\Device\HarddiskVolume2\testdir~WRD0000.tmp’
IRP_MJ_SET_INFORMATION Create: ‘0’ Cleanup:
‘0’ Close: ‘0’ Temp!!! Rename from ‘\Device\HarddiskVolume2\testdir\New
Microsoft Word Document (2).doc’ to
‘\Device\HarddiskVolume2\testdir~WRL0001.tmp’ SO: ‘E1083E48’ File is
‘\Device\HarddiskVolume2\testdir\New Microsoft Word Document (2).doc’
IRP_MJ_SET_INFORMATION Create: ‘0’ Cleanup:
‘0’ Close: ‘0’ Temp!!! Rename from
‘\Device\HarddiskVolume2\testdir~WRD0000.tmp’ to
‘\Device\HarddiskVolume2\testdir\New Microsoft Word Document (2).doc’ SO:
‘E2E96440’ File is ‘\Device\HarddiskVolume2\testdir~WRD0000.tmp’
IRP_MJ_CLEANUP Create: ‘0’ Cleanup:
‘0’ Close: ‘0’ SO: ‘E2E96440’ File is
‘\Device\HarddiskVolume2\testdir\New Microsoft Word Document (2).doc’
IRP_MJ_CLOSE Create: ‘17’ Cleanup:
‘17’ Close: ‘17’ SO: ‘E2E96440’ File is
‘\Device\HarddiskVolume2\testdir\New Microsoft Word Document (2).doc’
IRP_MJ_CREATE Create: ‘0’ Cleanup:
‘0’ Close: ‘0’ SO: ‘E2E96440’ File is
‘\Device\HarddiskVolume2\testdir\New Microsoft Word Document (2).doc’
IRP_MJ_CLEANUP Create: ‘0’ Cleanup:
‘0’ Close: ‘0’ SO: ‘E2E96440’ File is
‘\Device\HarddiskVolume2\testdir\New Microsoft Word Document (2).doc’
IRP_MJ_CLOSE Create: ‘18’ Cleanup:
‘18’ Close: ‘18’ SO: ‘E2E96440’ File is
‘\Device\HarddiskVolume2\testdir\New Microsoft Word Document (2).doc’
IRP_MJ_CLEANUP Create: ‘0’ Cleanup:
‘0’ Close: ‘0’ DELETE! SO: ‘E1083E48’ File is
‘\Device\HarddiskVolume2\testdir~WRL0001.tmp’

Bjorn

You are writing a minifilter derived from ctx and minispy. The osr article
on tracking state and context referecne counting is relevant to tradtional
(aka legacy) fitler drivers which for whatever reason can not use per stream
contexts; it is not relevant to mini filter drivers. The filter management
framework performs the context management (it uses per stream contexts etc)
in your behalf; part of the wonder of filter manager :slight_smile:

Cheers
Lyndon

“bjorn haake” wrote in message news:xxxxx@ntfsd…
> Hi All,
>
> I am still struggling with Context Management. I have read the article
> “Tracking State and Context - Reference Counting for File System Filter
> Drivers” on the OSR web site. I also combined the ctx and minispy sample
> to create a sample driver that detects file changes. I am still a bit lost
> though on the context management. I am trying to set a few flags in an
> operation, then check for those flags in the close (on the same stream
> object). I have some sample output below from a save of a word document. I
> thought the following strategy useful for word: in PreWrite check for
> IRP_NOCACHE and set flag. If in rename this flag is set it’s not a
> straight rename but a word (or powerpoint or other ) save that uses
> renaming rather than straight writes. In the below output, the IRP_NOCACHE
> is set on the streamobject with address 0xE2E96440. When I check the
> rename on that same address the flag is no longer set and the create count
> is 0 again. So do I still need to use FsRtlInsertPerStreamContext and
> FsRtlRemovePerStreamContext and the suggested algorithms in the article?
> Is this because streams are different even though they have the same
> address (address is being reused?) and I really need to just use the
> per-file context?
>
> Thanks, bjorn
>
> PS: Here’s the sample output with IRP, Counters, Flags set, stream object
> address and filename.
>
> IRP_MJ_CLOSE Create: ‘2’ Cleanup:
> ‘1’ Close: ‘1’ File Create! SO: ‘E2E96440’ File is
> ‘\Device\HarddiskVolume2\testdir~WRD0000.tmp’
> IRP_MJ_CLOSE Create: ‘9’ Cleanup:
> ‘9’ Close: ‘8’ NOCACHE WRITE!! SO: ‘E2E96440’ File is
> ‘\Device\HarddiskVolume2\testdir~WRD0000.tmp’
> IRP_MJ_SET_INFORMATION Create: ‘0’ Cleanup:
> ‘0’ Close: ‘0’ Temp!!! Rename from
> ‘\Device\HarddiskVolume2\testdir\New Microsoft Word Document (2).doc’ to
> ‘\Device\HarddiskVolume2\testdir~WRL0001.tmp’ SO: ‘E1083E48’ File is
> ‘\Device\HarddiskVolume2\testdir\New Microsoft Word Document (2).doc’
> IRP_MJ_SET_INFORMATION Create: ‘0’ Cleanup:
> ‘0’ Close: ‘0’ Temp!!! Rename from
> ‘\Device\HarddiskVolume2\testdir~WRD0000.tmp’ to
> ‘\Device\HarddiskVolume2\testdir\New Microsoft Word Document (2).doc’
> SO: ‘E2E96440’ File is ‘\Device\HarddiskVolume2\testdir~WRD0000.tmp’
> IRP_MJ_CLEANUP Create: ‘0’ Cleanup:
> ‘0’ Close: ‘0’ SO: ‘E2E96440’ File is
> ‘\Device\HarddiskVolume2\testdir\New Microsoft Word Document (2).doc’
> IRP_MJ_CLOSE Create: ‘17’ Cleanup:
> ‘17’ Close: ‘17’ SO: ‘E2E96440’ File is
> ‘\Device\HarddiskVolume2\testdir\New Microsoft Word Document (2).doc’
> IRP_MJ_CREATE Create: ‘0’ Cleanup:
> ‘0’ Close: ‘0’ SO: ‘E2E96440’ File is
> ‘\Device\HarddiskVolume2\testdir\New Microsoft Word Document (2).doc’
> IRP_MJ_CLEANUP Create: ‘0’ Cleanup:
> ‘0’ Close: ‘0’ SO: ‘E2E96440’ File is
> ‘\Device\HarddiskVolume2\testdir\New Microsoft Word Document (2).doc’
> IRP_MJ_CLOSE Create: ‘18’ Cleanup:
> ‘18’ Close: ‘18’ SO: ‘E2E96440’ File is
> ‘\Device\HarddiskVolume2\testdir\New Microsoft Word Document (2).doc’
> IRP_MJ_CLEANUP Create: ‘0’ Cleanup:
> ‘0’ Close: ‘0’ DELETE! SO: ‘E1083E48’ File is
> ‘\Device\HarddiskVolume2\testdir~WRL0001.tmp’
>
>
>

Thanks Lyndon. I had a stupid mistake in my code which is why it appeared
that the flag I had set in postwrite was cleared before the close.

I do have an add-on question: Is there an API that gives me the ref count so
I know when the last close came in? So far I have cleared my flag in the
first close encountered so I won’t be sending the operation to user space
multiple times. This leads to other problems and I don’t think that it’s a
good approach anyway.

Thanks, bjorn

“Lyndon J Clarke” wrote in message
news:xxxxx@ntfsd…
> Bjorn
>
> You are writing a minifilter derived from ctx and minispy. The osr article
> on tracking state and context referecne counting is relevant to tradtional
> (aka legacy) fitler drivers which for whatever reason can not use per
> stream contexts; it is not relevant to mini filter drivers. The filter
> management framework performs the context management (it uses per stream
> contexts etc) in your behalf; part of the wonder of filter manager :slight_smile:
>
> Cheers
> Lyndon
>
> “bjorn haake” wrote in message news:xxxxx@ntfsd…
>> Hi All,
>>
>> I am still struggling with Context Management. I have read the article
>> “Tracking State and Context - Reference Counting for File System Filter
>> Drivers” on the OSR web site. I also combined the ctx and minispy sample
>> to create a sample driver that detects file changes. I am still a bit
>> lost though on the context management. I am trying to set a few flags in
>> an operation, then check for those flags in the close (on the same stream
>> object). I have some sample output below from a save of a word document.
>> I thought the following strategy useful for word: in PreWrite check for
>> IRP_NOCACHE and set flag. If in rename this flag is set it’s not a
>> straight rename but a word (or powerpoint or other ) save that uses
>> renaming rather than straight writes. In the below output, the
>> IRP_NOCACHE is set on the streamobject with address 0xE2E96440. When I
>> check the rename on that same address the flag is no longer set and the
>> create count is 0 again. So do I still need to use
>> FsRtlInsertPerStreamContext and FsRtlRemovePerStreamContext and the
>> suggested algorithms in the article? Is this because streams are
>> different even though they have the same address (address is being
>> reused?) and I really need to just use the per-file context?
>>
>> Thanks, bjorn
>>
>> PS: Here’s the sample output with IRP, Counters, Flags set, stream object
>> address and filename.
>>
>> IRP_MJ_CLOSE Create: ‘2’ Cleanup:
>> ‘1’ Close: ‘1’ File Create! SO: ‘E2E96440’ File is
>> ‘\Device\HarddiskVolume2\testdir~WRD0000.tmp’
>> IRP_MJ_CLOSE Create: ‘9’ Cleanup:
>> ‘9’ Close: ‘8’ NOCACHE WRITE!! SO: ‘E2E96440’ File is
>> ‘\Device\HarddiskVolume2\testdir~WRD0000.tmp’
>> IRP_MJ_SET_INFORMATION Create: ‘0’ Cleanup:
>> ‘0’ Close: ‘0’ Temp!!! Rename from
>> ‘\Device\HarddiskVolume2\testdir\New Microsoft Word Document (2).doc’ to
>> ‘\Device\HarddiskVolume2\testdir~WRL0001.tmp’ SO: ‘E1083E48’ File is
>> ‘\Device\HarddiskVolume2\testdir\New Microsoft Word Document (2).doc’
>> IRP_MJ_SET_INFORMATION Create: ‘0’ Cleanup:
>> ‘0’ Close: ‘0’ Temp!!! Rename from
>> ‘\Device\HarddiskVolume2\testdir~WRD0000.tmp’ to
>> ‘\Device\HarddiskVolume2\testdir\New Microsoft Word Document (2).doc’ SO:
>> ‘E2E96440’ File is ‘\Device\HarddiskVolume2\testdir~WRD0000.tmp’
>> IRP_MJ_CLEANUP Create: ‘0’ Cleanup:
>> ‘0’ Close: ‘0’ SO: ‘E2E96440’ File is
>> ‘\Device\HarddiskVolume2\testdir\New Microsoft Word Document (2).doc’
>> IRP_MJ_CLOSE Create: ‘17’
>> Cleanup: ‘17’ Close: ‘17’ SO: ‘E2E96440’ File is
>> ‘\Device\HarddiskVolume2\testdir\New Microsoft Word Document (2).doc’
>> IRP_MJ_CREATE Create: ‘0’ Cleanup:
>> ‘0’ Close: ‘0’ SO: ‘E2E96440’ File is
>> ‘\Device\HarddiskVolume2\testdir\New Microsoft Word Document (2).doc’
>> IRP_MJ_CLEANUP Create: ‘0’ Cleanup:
>> ‘0’ Close: ‘0’ SO: ‘E2E96440’ File is
>> ‘\Device\HarddiskVolume2\testdir\New Microsoft Word Document (2).doc’
>> IRP_MJ_CLOSE Create: ‘18’
>> Cleanup: ‘18’ Close: ‘18’ SO: ‘E2E96440’ File is
>> ‘\Device\HarddiskVolume2\testdir\New Microsoft Word Document (2).doc’
>> IRP_MJ_CLEANUP Create: ‘0’ Cleanup:
>> ‘0’ Close: ‘0’ DELETE! SO: ‘E1083E48’ File is
>> ‘\Device\HarddiskVolume2\testdir~WRL0001.tmp’
>>
>>
>>
>
>
>

Bjorne

I dont know of such an api. Here howeber is a suggestion. Instead of telling
your userspace about IRP_MJ_CLOSE instyead tell your userspace about the
context teardown.

Cheers
Lyndon

“bjorn haake” wrote in message news:xxxxx@ntfsd…
> Thanks Lyndon. I had a stupid mistake in my code which is why it appeared
> that the flag I had set in postwrite was cleared before the close.
>
> I do have an add-on question: Is there an API that gives me the ref count
> so I know when the last close came in? So far I have cleared my flag in
> the first close encountered so I won’t be sending the operation to user
> space multiple times. This leads to other problems and I don’t think that
> it’s a good approach anyway.
>
> Thanks, bjorn
>
>
>
> “Lyndon J Clarke” wrote in message
> news:xxxxx@ntfsd…
>> Bjorn
>>
>> You are writing a minifilter derived from ctx and minispy. The osr
>> article on tracking state and context referecne counting is relevant to
>> tradtional (aka legacy) fitler drivers which for whatever reason can not
>> use per stream contexts; it is not relevant to mini filter drivers. The
>> filter management framework performs the context management (it uses per
>> stream contexts etc) in your behalf; part of the wonder of filter manager
>> :slight_smile:
>>
>> Cheers
>> Lyndon
>>
>> “bjorn haake” wrote in message news:xxxxx@ntfsd…
>>> Hi All,
>>>
>>> I am still struggling with Context Management. I have read the article
>>> “Tracking State and Context - Reference Counting for File System Filter
>>> Drivers” on the OSR web site. I also combined the ctx and minispy sample
>>> to create a sample driver that detects file changes. I am still a bit
>>> lost though on the context management. I am trying to set a few flags in
>>> an operation, then check for those flags in the close (on the same
>>> stream object). I have some sample output below from a save of a word
>>> document. I thought the following strategy useful for word: in PreWrite
>>> check for IRP_NOCACHE and set flag. If in rename this flag is set it’s
>>> not a straight rename but a word (or powerpoint or other ) save that
>>> uses renaming rather than straight writes. In the below output, the
>>> IRP_NOCACHE is set on the streamobject with address 0xE2E96440. When I
>>> check the rename on that same address the flag is no longer set and the
>>> create count is 0 again. So do I still need to use
>>> FsRtlInsertPerStreamContext and FsRtlRemovePerStreamContext and the
>>> suggested algorithms in the article? Is this because streams are
>>> different even though they have the same address (address is being
>>> reused?) and I really need to just use the per-file context?
>>>
>>> Thanks, bjorn
>>>
>>> PS: Here’s the sample output with IRP, Counters, Flags set, stream
>>> object address and filename.
>>>
>>> IRP_MJ_CLOSE Create: ‘2’
>>> Cleanup: ‘1’ Close: ‘1’ File Create! SO: ‘E2E96440’ File is
>>> ‘\Device\HarddiskVolume2\testdir~WRD0000.tmp’
>>> IRP_MJ_CLOSE Create: ‘9’
>>> Cleanup: ‘9’ Close: ‘8’ NOCACHE WRITE!! SO: ‘E2E96440’ File is
>>> ‘\Device\HarddiskVolume2\testdir~WRD0000.tmp’
>>> IRP_MJ_SET_INFORMATION Create: ‘0’
>>> Cleanup: ‘0’ Close: ‘0’ Temp!!! Rename from
>>> ‘\Device\HarddiskVolume2\testdir\New Microsoft Word Document (2).doc’ to
>>> ‘\Device\HarddiskVolume2\testdir~WRL0001.tmp’ SO: ‘E1083E48’ File
>>> is ‘\Device\HarddiskVolume2\testdir\New Microsoft Word Document (2).doc’
>>> IRP_MJ_SET_INFORMATION Create: ‘0’
>>> Cleanup: ‘0’ Close: ‘0’ Temp!!! Rename from
>>> ‘\Device\HarddiskVolume2\testdir~WRD0000.tmp’ to
>>> ‘\Device\HarddiskVolume2\testdir\New Microsoft Word Document (2).doc’
>>> SO: ‘E2E96440’ File is ‘\Device\HarddiskVolume2\testdir~WRD0000.tmp’
>>> IRP_MJ_CLEANUP Create: ‘0’
>>> Cleanup: ‘0’ Close: ‘0’ SO: ‘E2E96440’ File is
>>> ‘\Device\HarddiskVolume2\testdir\New Microsoft Word Document (2).doc’
>>> IRP_MJ_CLOSE Create: ‘17’ Cleanup:
>>> ‘17’ Close: ‘17’ SO: ‘E2E96440’ File is
>>> ‘\Device\HarddiskVolume2\testdir\New Microsoft Word Document (2).doc’
>>> IRP_MJ_CREATE Create: ‘0’
>>> Cleanup: ‘0’ Close: ‘0’ SO: ‘E2E96440’ File is
>>> ‘\Device\HarddiskVolume2\testdir\New Microsoft Word Document (2).doc’
>>> IRP_MJ_CLEANUP Create: ‘0’
>>> Cleanup: ‘0’ Close: ‘0’ SO: ‘E2E96440’ File is
>>> ‘\Device\HarddiskVolume2\testdir\New Microsoft Word Document (2).doc’
>>> IRP_MJ_CLOSE Create: ‘18’ Cleanup:
>>> ‘18’ Close: ‘18’ SO: ‘E2E96440’ File is
>>> ‘\Device\HarddiskVolume2\testdir\New Microsoft Word Document (2).doc’
>>> IRP_MJ_CLEANUP Create: ‘0’
>>> Cleanup: ‘0’ Close: ‘0’ DELETE! SO: ‘E1083E48’ File is
>>> ‘\Device\HarddiskVolume2\testdir~WRL0001.tmp’
>>>
>>>
>>>
>>
>>
>>
>
>
>

I guess I am still missing something. According to the documentation, a call
to FltReleaseContext will free the context when the ref count hits 0. I
assume you meant to pass up the info at this point?
I assume in the ctx sample, this freeing is done in the function
CtxContextCleanup. However, I set a breakpoint there, and while for a Word
save it was hit, for other apps like Notepad it was not (not even when
closing the application). Is there another way that contexts can be torn
down (e.g. through the FilterManager)?

Thanks, bjorn

“Lyndon J Clarke” wrote in message
news:xxxxx@ntfsd…
> Bjorne
>
> I dont know of such an api. Here howeber is a suggestion. Instead of
> telling your userspace about IRP_MJ_CLOSE instyead tell your userspace
> about the context teardown.
>
> Cheers
> Lyndon
>
> “bjorn haake” wrote in message news:xxxxx@ntfsd…
>> Thanks Lyndon. I had a stupid mistake in my code which is why it appeared
>> that the flag I had set in postwrite was cleared before the close.
>>
>> I do have an add-on question: Is there an API that gives me the ref count
>> so I know when the last close came in? So far I have cleared my flag in
>> the first close encountered so I won’t be sending the operation to user
>> space multiple times. This leads to other problems and I don’t think that
>> it’s a good approach anyway.
>>
>> Thanks, bjorn
>>
>>
>>
>> “Lyndon J Clarke” wrote in message
>> news:xxxxx@ntfsd…
>>> Bjorn
>>>
>>> You are writing a minifilter derived from ctx and minispy. The osr
>>> article on tracking state and context referecne counting is relevant to
>>> tradtional (aka legacy) fitler drivers which for whatever reason can not
>>> use per stream contexts; it is not relevant to mini filter drivers. The
>>> filter management framework performs the context management (it uses per
>>> stream contexts etc) in your behalf; part of the wonder of filter
>>> manager :slight_smile:
>>>
>>> Cheers
>>> Lyndon
>>>
>>> “bjorn haake” wrote in message news:xxxxx@ntfsd…
>>>> Hi All,
>>>>
>>>> I am still struggling with Context Management. I have read the article
>>>> “Tracking State and Context - Reference Counting for File System Filter
>>>> Drivers” on the OSR web site. I also combined the ctx and minispy
>>>> sample to create a sample driver that detects file changes. I am still
>>>> a bit lost though on the context management. I am trying to set a few
>>>> flags in an operation, then check for those flags in the close (on the
>>>> same stream object). I have some sample output below from a save of a
>>>> word document. I thought the following strategy useful for word: in
>>>> PreWrite check for IRP_NOCACHE and set flag. If in rename this flag is
>>>> set it’s not a straight rename but a word (or powerpoint or other )
>>>> save that uses renaming rather than straight writes. In the below
>>>> output, the IRP_NOCACHE is set on the streamobject with address
>>>> 0xE2E96440. When I check the rename on that same address the flag is no
>>>> longer set and the create count is 0 again. So do I still need to use
>>>> FsRtlInsertPerStreamContext and FsRtlRemovePerStreamContext and the
>>>> suggested algorithms in the article? Is this because streams are
>>>> different even though they have the same address (address is being
>>>> reused?) and I really need to just use the per-file context?
>>>>
>>>> Thanks, bjorn
>>>>
>>>> PS: Here’s the sample output with IRP, Counters, Flags set, stream
>>>> object address and filename.
>>>>
>>>> IRP_MJ_CLOSE Create: ‘2’ Cleanup:
>>>> ‘1’ Close: ‘1’ File Create! SO: ‘E2E96440’ File is
>>>> ‘\Device\HarddiskVolume2\testdir~WRD0000.tmp’
>>>> IRP_MJ_CLOSE Create: ‘9’ Cleanup:
>>>> ‘9’ Close: ‘8’ NOCACHE WRITE!! SO: ‘E2E96440’ File is
>>>> ‘\Device\HarddiskVolume2\testdir~WRD0000.tmp’
>>>> IRP_MJ_SET_INFORMATION Create: ‘0’ Cleanup:
>>>> ‘0’ Close: ‘0’ Temp!!! Rename from
>>>> ‘\Device\HarddiskVolume2\testdir\New Microsoft Word Document (2).doc’
>>>> to ‘\Device\HarddiskVolume2\testdir~WRL0001.tmp’ SO: ‘E1083E48’
>>>> File is ‘\Device\HarddiskVolume2\testdir\New Microsoft Word Document
>>>> (2).doc’
>>>> IRP_MJ_SET_INFORMATION Create: ‘0’ Cleanup:
>>>> ‘0’ Close: ‘0’ Temp!!! Rename from
>>>> ‘\Device\HarddiskVolume2\testdir~WRD0000.tmp’ to
>>>> ‘\Device\HarddiskVolume2\testdir\New Microsoft Word Document (2).doc’
>>>> SO: ‘E2E96440’ File is
>>>> ‘\Device\HarddiskVolume2\testdir~WRD0000.tmp’
>>>> IRP_MJ_CLEANUP Create: ‘0’ Cleanup:
>>>> ‘0’ Close: ‘0’ SO: ‘E2E96440’ File is
>>>> ‘\Device\HarddiskVolume2\testdir\New Microsoft Word Document (2).doc’
>>>> IRP_MJ_CLOSE Create: ‘17’ Cleanup:
>>>> ‘17’ Close: ‘17’ SO: ‘E2E96440’ File is
>>>> ‘\Device\HarddiskVolume2\testdir\New Microsoft Word Document (2).doc’
>>>> IRP_MJ_CREATE Create: ‘0’ Cleanup:
>>>> ‘0’ Close: ‘0’ SO: ‘E2E96440’ File is
>>>> ‘\Device\HarddiskVolume2\testdir\New Microsoft Word Document (2).doc’
>>>> IRP_MJ_CLEANUP Create: ‘0’ Cleanup:
>>>> ‘0’ Close: ‘0’ SO: ‘E2E96440’ File is
>>>> ‘\Device\HarddiskVolume2\testdir\New Microsoft Word Document (2).doc’
>>>> IRP_MJ_CLOSE Create: ‘18’ Cleanup:
>>>> ‘18’ Close: ‘18’ SO: ‘E2E96440’ File is
>>>> ‘\Device\HarddiskVolume2\testdir\New Microsoft Word Document (2).doc’
>>>> IRP_MJ_CLEANUP Create: ‘0’ Cleanup:
>>>> ‘0’ Close: ‘0’ DELETE! SO: ‘E1083E48’ File is
>>>> ‘\Device\HarddiskVolume2\testdir~WRL0001.tmp’
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>>
>
>
>

Bjorn

This is normal behavior and should come as no surprise. The cache manager
function CcInitializeCacheMap initiates caching for the file (stream). The
cache manager keeps a reference to the file object passed to this call until
caching is terminated for the file even if the handle has been closed. It
can keep the reference for a long time if resources are plentiful. It should
be an optimization for the common case of a file which is opened,
read/write, and closed and then is soon re-opened. I am pretty sure this has
come up on the list a lot of times to a search of the archive might be a
good idea. I have the empirical impression that the system tends to hang
onto that file object reference for a very long time indeed in the case of a
file which has been memory mapped; and it so happens that notepad memory
maps the file.

Good luck
Lyndon

“bjorn haake” wrote in message news:xxxxx@ntfsd…
>I guess I am still missing something. According to the documentation, a
>call to FltReleaseContext will free the context when the ref count hits 0.
>I assume you meant to pass up the info at this point?
> I assume in the ctx sample, this freeing is done in the function
> CtxContextCleanup. However, I set a breakpoint there, and while for a Word
> save it was hit, for other apps like Notepad it was not (not even when
> closing the application). Is there another way that contexts can be torn
> down (e.g. through the FilterManager)?
>
> Thanks, bjorn
>
>
>
> “Lyndon J Clarke” wrote in message
> news:xxxxx@ntfsd…
>> Bjorne
>>
>> I dont know of such an api. Here howeber is a suggestion. Instead of
>> telling your userspace about IRP_MJ_CLOSE instyead tell your userspace
>> about the context teardown.
>>
>> Cheers
>> Lyndon
>>
>> “bjorn haake” wrote in message news:xxxxx@ntfsd…
>>> Thanks Lyndon. I had a stupid mistake in my code which is why it
>>> appeared that the flag I had set in postwrite was cleared before the
>>> close.
>>>
>>> I do have an add-on question: Is there an API that gives me the ref
>>> count so I know when the last close came in? So far I have cleared my
>>> flag in the first close encountered so I won’t be sending the operation
>>> to user space multiple times. This leads to other problems and I don’t
>>> think that it’s a good approach anyway.
>>>
>>> Thanks, bjorn
>>>
>>>
>>>
>>> “Lyndon J Clarke” wrote in message
>>> news:xxxxx@ntfsd…
>>>> Bjorn
>>>>
>>>> You are writing a minifilter derived from ctx and minispy. The osr
>>>> article on tracking state and context referecne counting is relevant to
>>>> tradtional (aka legacy) fitler drivers which for whatever reason can
>>>> not use per stream contexts; it is not relevant to mini filter drivers.
>>>> The filter management framework performs the context management (it
>>>> uses per stream contexts etc) in your behalf; part of the wonder of
>>>> filter manager :slight_smile:
>>>>
>>>> Cheers
>>>> Lyndon
>>>>
>>>> “bjorn haake” wrote in message news:xxxxx@ntfsd…
>>>>> Hi All,
>>>>>
>>>>> I am still struggling with Context Management. I have read the article
>>>>> “Tracking State and Context - Reference Counting for File System
>>>>> Filter Drivers” on the OSR web site. I also combined the ctx and
>>>>> minispy sample to create a sample driver that detects file changes. I
>>>>> am still a bit lost though on the context management. I am trying to
>>>>> set a few flags in an operation, then check for those flags in the
>>>>> close (on the same stream object). I have some sample output below
>>>>> from a save of a word document. I thought the following strategy
>>>>> useful for word: in PreWrite check for IRP_NOCACHE and set flag. If in
>>>>> rename this flag is set it’s not a straight rename but a word (or
>>>>> powerpoint or other ) save that uses renaming rather than straight
>>>>> writes. In the below output, the IRP_NOCACHE is set on the
>>>>> streamobject with address 0xE2E96440. When I check the rename on that
>>>>> same address the flag is no longer set and the create count is 0
>>>>> again. So do I still need to use FsRtlInsertPerStreamContext and
>>>>> FsRtlRemovePerStreamContext and the suggested algorithms in the
>>>>> article? Is this because streams are different even though they have
>>>>> the same address (address is being reused?) and I really need to just
>>>>> use the per-file context?
>>>>>
>>>>> Thanks, bjorn
>>>>>
>>>>> PS: Here’s the sample output with IRP, Counters, Flags set, stream
>>>>> object address and filename.
>>>>>
>>>>> IRP_MJ_CLOSE Create: ‘2’ Cleanup:
>>>>> ‘1’ Close: ‘1’ File Create! SO: ‘E2E96440’ File is
>>>>> ‘\Device\HarddiskVolume2\testdir~WRD0000.tmp’
>>>>> IRP_MJ_CLOSE Create: ‘9’ Cleanup:
>>>>> ‘9’ Close: ‘8’ NOCACHE WRITE!! SO: ‘E2E96440’ File is
>>>>> ‘\Device\HarddiskVolume2\testdir~WRD0000.tmp’
>>>>> IRP_MJ_SET_INFORMATION Create: ‘0’ Cleanup:
>>>>> ‘0’ Close: ‘0’ Temp!!! Rename from
>>>>> ‘\Device\HarddiskVolume2\testdir\New Microsoft Word Document (2).doc’
>>>>> to ‘\Device\HarddiskVolume2\testdir~WRL0001.tmp’ SO: ‘E1083E48’
>>>>> File is ‘\Device\HarddiskVolume2\testdir\New Microsoft Word Document
>>>>> (2).doc’
>>>>> IRP_MJ_SET_INFORMATION Create: ‘0’ Cleanup:
>>>>> ‘0’ Close: ‘0’ Temp!!! Rename from
>>>>> ‘\Device\HarddiskVolume2\testdir~WRD0000.tmp’ to
>>>>> ‘\Device\HarddiskVolume2\testdir\New Microsoft Word Document (2).doc’
>>>>> SO: ‘E2E96440’ File is ‘\Device\HarddiskVolume2\testdir~WRD0000.tmp’
>>>>> IRP_MJ_CLEANUP Create: ‘0’ Cleanup:
>>>>> ‘0’ Close: ‘0’ SO: ‘E2E96440’ File is
>>>>> ‘\Device\HarddiskVolume2\testdir\New Microsoft Word Document (2).doc’
>>>>> IRP_MJ_CLOSE Create: ‘17’
>>>>> Cleanup: ‘17’ Close: ‘17’ SO: ‘E2E96440’ File is
>>>>> ‘\Device\HarddiskVolume2\testdir\New Microsoft Word Document (2).doc’
>>>>> IRP_MJ_CREATE Create: ‘0’ Cleanup:
>>>>> ‘0’ Close: ‘0’ SO: ‘E2E96440’ File is
>>>>> ‘\Device\HarddiskVolume2\testdir\New Microsoft Word Document (2).doc’
>>>>> IRP_MJ_CLEANUP Create: ‘0’ Cleanup:
>>>>> ‘0’ Close: ‘0’ SO: ‘E2E96440’ File is
>>>>> ‘\Device\HarddiskVolume2\testdir\New Microsoft Word Document (2).doc’
>>>>> IRP_MJ_CLOSE Create: ‘18’
>>>>> Cleanup: ‘18’ Close: ‘18’ SO: ‘E2E96440’ File is
>>>>> ‘\Device\HarddiskVolume2\testdir\New Microsoft Word Document (2).doc’
>>>>> IRP_MJ_CLEANUP Create: ‘0’ Cleanup:
>>>>> ‘0’ Close: ‘0’ DELETE! SO: ‘E1083E48’ File is
>>>>> ‘\Device\HarddiskVolume2\testdir~WRL0001.tmp’
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>>
>
>
>

I see now. Seems like the approach I chose (use my own flags and clear them
in first close) doesn’t seem like too bad of an idea after all…

Thanks again for all your help, bjorn

“Lyndon J Clarke” wrote in message
news:xxxxx@ntfsd…
> Bjorn
>
> This is normal behavior and should come as no surprise. The cache manager
> function CcInitializeCacheMap initiates caching for the file (stream). The
> cache manager keeps a reference to the file object passed to this call
> until caching is terminated for the file even if the handle has been
> closed. It can keep the reference for a long time if resources are
> plentiful. It should be an optimization for the common case of a file
> which is opened, read/write, and closed and then is soon re-opened. I am
> pretty sure this has come up on the list a lot of times to a search of the
> archive might be a good idea. I have the empirical impression that the
> system tends to hang onto that file object reference for a very long time
> indeed in the case of a file which has been memory mapped; and it so
> happens that notepad memory maps the file.
>
> Good luck
> Lyndon
>
> “bjorn haake” wrote in message news:xxxxx@ntfsd…
>>I guess I am still missing something. According to the documentation, a
>>call to FltReleaseContext will free the context when the ref count hits 0.
>>I assume you meant to pass up the info at this point?
>> I assume in the ctx sample, this freeing is done in the function
>> CtxContextCleanup. However, I set a breakpoint there, and while for a
>> Word save it was hit, for other apps like Notepad it was not (not even
>> when closing the application). Is there another way that contexts can be
>> torn down (e.g. through the FilterManager)?
>>
>> Thanks, bjorn
>>
>>
>>
>> “Lyndon J Clarke” wrote in message
>> news:xxxxx@ntfsd…
>>> Bjorne
>>>
>>> I dont know of such an api. Here howeber is a suggestion. Instead of
>>> telling your userspace about IRP_MJ_CLOSE instyead tell your userspace
>>> about the context teardown.
>>>
>>> Cheers
>>> Lyndon
>>>
>>> “bjorn haake” wrote in message news:xxxxx@ntfsd…
>>>> Thanks Lyndon. I had a stupid mistake in my code which is why it
>>>> appeared that the flag I had set in postwrite was cleared before the
>>>> close.
>>>>
>>>> I do have an add-on question: Is there an API that gives me the ref
>>>> count so I know when the last close came in? So far I have cleared my
>>>> flag in the first close encountered so I won’t be sending the operation
>>>> to user space multiple times. This leads to other problems and I don’t
>>>> think that it’s a good approach anyway.
>>>>
>>>> Thanks, bjorn
>>>>
>>>>
>>>>
>>>> “Lyndon J Clarke” wrote in message
>>>> news:xxxxx@ntfsd…
>>>>> Bjorn
>>>>>
>>>>> You are writing a minifilter derived from ctx and minispy. The osr
>>>>> article on tracking state and context referecne counting is relevant
>>>>> to tradtional (aka legacy) fitler drivers which for whatever reason
>>>>> can not use per stream contexts; it is not relevant to mini filter
>>>>> drivers. The filter management framework performs the context
>>>>> management (it uses per stream contexts etc) in your behalf; part of
>>>>> the wonder of filter manager :slight_smile:
>>>>>
>>>>> Cheers
>>>>> Lyndon
>>>>>
>>>>> “bjorn haake” wrote in message news:xxxxx@ntfsd…
>>>>>> Hi All,
>>>>>>
>>>>>> I am still struggling with Context Management. I have read the
>>>>>> article “Tracking State and Context - Reference Counting for File
>>>>>> System Filter Drivers” on the OSR web site. I also combined the ctx
>>>>>> and minispy sample to create a sample driver that detects file
>>>>>> changes. I am still a bit lost though on the context management. I am
>>>>>> trying to set a few flags in an operation, then check for those flags
>>>>>> in the close (on the same stream object). I have some sample output
>>>>>> below from a save of a word document. I thought the following
>>>>>> strategy useful for word: in PreWrite check for IRP_NOCACHE and set
>>>>>> flag. If in rename this flag is set it’s not a straight rename but a
>>>>>> word (or powerpoint or other ) save that uses renaming rather than
>>>>>> straight writes. In the below output, the IRP_NOCACHE is set on the
>>>>>> streamobject with address 0xE2E96440. When I check the rename on that
>>>>>> same address the flag is no longer set and the create count is 0
>>>>>> again. So do I still need to use FsRtlInsertPerStreamContext and
>>>>>> FsRtlRemovePerStreamContext and the suggested algorithms in the
>>>>>> article? Is this because streams are different even though they have
>>>>>> the same address (address is being reused?) and I really need to just
>>>>>> use the per-file context?
>>>>>>
>>>>>> Thanks, bjorn
>>>>>>
>>>>>> PS: Here’s the sample output with IRP, Counters, Flags set, stream
>>>>>> object address and filename.
>>>>>>
>>>>>> IRP_MJ_CLOSE Create: ‘2’
>>>>>> Cleanup: ‘1’ Close: ‘1’ File Create! SO: ‘E2E96440’ File is
>>>>>> ‘\Device\HarddiskVolume2\testdir~WRD0000.tmp’
>>>>>> IRP_MJ_CLOSE Create: ‘9’
>>>>>> Cleanup: ‘9’ Close: ‘8’ NOCACHE WRITE!! SO: ‘E2E96440’ File is
>>>>>> ‘\Device\HarddiskVolume2\testdir~WRD0000.tmp’
>>>>>> IRP_MJ_SET_INFORMATION Create: ‘0’
>>>>>> Cleanup: ‘0’ Close: ‘0’ Temp!!! Rename from
>>>>>> ‘\Device\HarddiskVolume2\testdir\New Microsoft Word Document (2).doc’
>>>>>> to ‘\Device\HarddiskVolume2\testdir~WRL0001.tmp’ SO: ‘E1083E48’
>>>>>> File is ‘\Device\HarddiskVolume2\testdir\New Microsoft Word Document
>>>>>> (2).doc’
>>>>>> IRP_MJ_SET_INFORMATION Create: ‘0’
>>>>>> Cleanup: ‘0’ Close: ‘0’ Temp!!! Rename from
>>>>>> ‘\Device\HarddiskVolume2\testdir~WRD0000.tmp’ to
>>>>>> ‘\Device\HarddiskVolume2\testdir\New Microsoft Word Document (2).doc’
>>>>>> SO: ‘E2E96440’ File is
>>>>>> ‘\Device\HarddiskVolume2\testdir~WRD0000.tmp’
>>>>>> IRP_MJ_CLEANUP Create: ‘0’
>>>>>> Cleanup: ‘0’ Close: ‘0’ SO: ‘E2E96440’ File is
>>>>>> ‘\Device\HarddiskVolume2\testdir\New Microsoft Word Document (2).doc’
>>>>>> IRP_MJ_CLOSE Create: ‘17’
>>>>>> Cleanup: ‘17’ Close: ‘17’ SO: ‘E2E96440’ File is
>>>>>> ‘\Device\HarddiskVolume2\testdir\New Microsoft Word Document (2).doc’
>>>>>> IRP_MJ_CREATE Create: ‘0’
>>>>>> Cleanup: ‘0’ Close: ‘0’ SO: ‘E2E96440’ File is
>>>>>> ‘\Device\HarddiskVolume2\testdir\New Microsoft Word Document (2).doc’
>>>>>> IRP_MJ_CLEANUP Create: ‘0’
>>>>>> Cleanup: ‘0’ Close: ‘0’ SO: ‘E2E96440’ File is
>>>>>> ‘\Device\HarddiskVolume2\testdir\New Microsoft Word Document (2).doc’
>>>>>> IRP_MJ_CLOSE Create: ‘18’
>>>>>> Cleanup: ‘18’ Close: ‘18’ SO: ‘E2E96440’ File is
>>>>>> ‘\Device\HarddiskVolume2\testdir\New Microsoft Word Document (2).doc’
>>>>>> IRP_MJ_CLEANUP Create: ‘0’
>>>>>> Cleanup: ‘0’ Close: ‘0’ DELETE! SO: ‘E1083E48’ File is
>>>>>> ‘\Device\HarddiskVolume2\testdir~WRL0001.tmp’
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>>
>
>
>

You aren’t missing anything, you just are not sufficiently patient.
Realize that because of the effects of caching a file may actually stay
in memory for an extended period of time (think hours or days.) Did you
try to encourage the system to flush out those pages by reading other
huge files? If not, try that - and I suspect you’ll see your context
disappear.

It is a common misconception amongst those new to this space that a user
closing a file has some relationship to the VM system releasing its
reference (and causing the ultimate file closure.) The entire purpose
of caching is to make sure that data stays around in memory as long as
it is useful.

Interesting note from last month’s FAST conference: 30 minutes is the
“magic number” for how long data is best kept in memory rather than
retrieved from disk (this from Jim Gray, Microsoft Research). What that
means is that if you plan on using that data in the next 30 minutes,
we’d rather keep it in memory than force you to go back out to disk…

Generally at least half the memory on your Windows system is used just
for file system data cache - we really do want to avoid going back to
disk if we can help it (I have a little file system I use for testing
our file system development kit that has no backing store - reads are
satisfied with zero filling and writes are discarded. It is incredibly
fast, which is what I wanted for testing. What’s amazing is that I can
do "xcopy /s/e/v c:\windows q:" (where “q:” is my volume) and it works

  • but I have no data storage, all of the data reads are satisfied from
    cache.

Regards,

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

Looking forward to seeing you at the next OSR File Systems class in
Boston, MA April 24-27, 2006.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of bjorn haake
Sent: Monday, January 09, 2006 2:22 PM
To: ntfsd redirect
Subject: Re:[ntfsd] Context Management Question

I guess I am still missing something. According to the documentation, a
call
to FltReleaseContext will free the context when the ref count hits 0. I
assume you meant to pass up the info at this point?
I assume in the ctx sample, this freeing is done in the function
CtxContextCleanup. However, I set a breakpoint there, and while for a
Word
save it was hit, for other apps like Notepad it was not (not even when
closing the application). Is there another way that contexts can be torn

down (e.g. through the FilterManager)?

Thanks, bjorn

“Lyndon J Clarke” wrote in message
news:xxxxx@ntfsd…
> Bjorne
>
> I dont know of such an api. Here howeber is a suggestion. Instead of
> telling your userspace about IRP_MJ_CLOSE instyead tell your userspace

> about the context teardown.
>
> Cheers
> Lyndon
>
> “bjorn haake” wrote in message news:xxxxx@ntfsd…
>> Thanks Lyndon. I had a stupid mistake in my code which is why it
appeared
>> that the flag I had set in postwrite was cleared before the close.
>>
>> I do have an add-on question: Is there an API that gives me the ref
count
>> so I know when the last close came in? So far I have cleared my flag
in
>> the first close encountered so I won’t be sending the operation to
user
>> space multiple times. This leads to other problems and I don’t think
that
>> it’s a good approach anyway.
>>
>> Thanks, bjorn
>>
>>
>>
>> “Lyndon J Clarke” wrote in message
>> news:xxxxx@ntfsd…
>>> Bjorn
>>>
>>> You are writing a minifilter derived from ctx and minispy. The osr
>>> article on tracking state and context referecne counting is relevant
to
>>> tradtional (aka legacy) fitler drivers which for whatever reason can
not
>>> use per stream contexts; it is not relevant to mini filter drivers.
The
>>> filter management framework performs the context management (it uses
per
>>> stream contexts etc) in your behalf; part of the wonder of filter
>>> manager :slight_smile:
>>>
>>> Cheers
>>> Lyndon
>>>
>>> “bjorn haake” wrote in message
news:xxxxx@ntfsd…
>>>> Hi All,
>>>>
>>>> I am still struggling with Context Management. I have read the
article
>>>> “Tracking State and Context - Reference Counting for File System
Filter
>>>> Drivers” on the OSR web site. I also combined the ctx and minispy
>>>> sample to create a sample driver that detects file changes. I am
still
>>>> a bit lost though on the context management. I am trying to set a
few
>>>> flags in an operation, then check for those flags in the close (on
the
>>>> same stream object). I have some sample output below from a save of
a
>>>> word document. I thought the following strategy useful for word: in

>>>> PreWrite check for IRP_NOCACHE and set flag. If in rename this flag
is
>>>> set it’s not a straight rename but a word (or powerpoint or other )

>>>> save that uses renaming rather than straight writes. In the below
>>>> output, the IRP_NOCACHE is set on the streamobject with address
>>>> 0xE2E96440. When I check the rename on that same address the flag
is no
>>>> longer set and the create count is 0 again. So do I still need to
use
>>>> FsRtlInsertPerStreamContext and FsRtlRemovePerStreamContext and the

>>>> suggested algorithms in the article? Is this because streams are
>>>> different even though they have the same address (address is being
>>>> reused?) and I really need to just use the per-file context?
>>>>
>>>> Thanks, bjorn
>>>>
>>>> PS: Here’s the sample output with IRP, Counters, Flags set, stream
>>>> object address and filename.
>>>>
>>>> IRP_MJ_CLOSE Create: ‘2’
Cleanup:
>>>> ‘1’ Close: ‘1’ File Create! SO: ‘E2E96440’ File is
>>>> ‘\Device\HarddiskVolume2\testdir~WRD0000.tmp’
>>>> IRP_MJ_CLOSE Create: ‘9’
Cleanup:
>>>> ‘9’ Close: ‘8’ NOCACHE WRITE!! SO: ‘E2E96440’ File is
>>>> ‘\Device\HarddiskVolume2\testdir~WRD0000.tmp’
>>>> IRP_MJ_SET_INFORMATION Create: ‘0’
Cleanup:
>>>> ‘0’ Close: ‘0’ Temp!!! Rename from
>>>> ‘\Device\HarddiskVolume2\testdir\New Microsoft Word Document
(2).doc’
>>>> to ‘\Device\HarddiskVolume2\testdir~WRL0001.tmp’ SO: ‘E1083E48’

>>>> File is ‘\Device\HarddiskVolume2\testdir\New Microsoft Word
Document
>>>> (2).doc’
>>>> IRP_MJ_SET_INFORMATION Create: ‘0’
Cleanup:
>>>> ‘0’ Close: ‘0’ Temp!!! Rename from
>>>> ‘\Device\HarddiskVolume2\testdir~WRD0000.tmp’ to
>>>> ‘\Device\HarddiskVolume2\testdir\New Microsoft Word Document
(2).doc’
>>>> SO: ‘E2E96440’ File is
>>>> ‘\Device\HarddiskVolume2\testdir~WRD0000.tmp’
>>>> IRP_MJ_CLEANUP Create: ‘0’
Cleanup:
>>>> ‘0’ Close: ‘0’ SO: ‘E2E96440’ File is
>>>> ‘\Device\HarddiskVolume2\testdir\New Microsoft Word Document
(2).doc’
>>>> IRP_MJ_CLOSE Create: ‘17’
Cleanup:
>>>> ‘17’ Close: ‘17’ SO: ‘E2E96440’ File is
>>>> ‘\Device\HarddiskVolume2\testdir\New Microsoft Word Document
(2).doc’
>>>> IRP_MJ_CREATE Create: ‘0’
Cleanup:
>>>> ‘0’ Close: ‘0’ SO: ‘E2E96440’ File is
>>>> ‘\Device\HarddiskVolume2\testdir\New Microsoft Word Document
(2).doc’
>>>> IRP_MJ_CLEANUP Create: ‘0’
Cleanup:
>>>> ‘0’ Close: ‘0’ SO: ‘E2E96440’ File is
>>>> ‘\Device\HarddiskVolume2\testdir\New Microsoft Word Document
(2).doc’
>>>> IRP_MJ_CLOSE Create: ‘18’
Cleanup:
>>>> ‘18’ Close: ‘18’ SO: ‘E2E96440’ File is
>>>> ‘\Device\HarddiskVolume2\testdir\New Microsoft Word Document
(2).doc’
>>>> IRP_MJ_CLEANUP Create: ‘0’
Cleanup:
>>>> ‘0’ Close: ‘0’ DELETE! SO: ‘E1083E48’ File is
>>>> ‘\Device\HarddiskVolume2\testdir~WRL0001.tmp’
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>>
>
>
>


Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

Thanks Tony, got that part understood now. I am still at a loss how to deal
with it. Currently, I set a flag in an operation - for example when I am
detecting a file copy. I check this flag in the close - I want to wait with
my notification until the file is done copying. So what I currently do in
the first close for that stream object I reset the flag (so I won’t get
additional notifications) and update the struct that’s being sent to user
space.
My question is, is that a safe practice? It seems to work so far (file
rename, copies, creates and most Office file change detection work ok). I am
just not sure though if there is something I am missing that could me hurt
me later…

Thanks, bjorn

“Tony Mason” wrote in message news:xxxxx@ntfsd…
You aren’t missing anything, you just are not sufficiently patient.
Realize that because of the effects of caching a file may actually stay
in memory for an extended period of time (think hours or days.) Did you
try to encourage the system to flush out those pages by reading other
huge files? If not, try that - and I suspect you’ll see your context
disappear.

It is a common misconception amongst those new to this space that a user
closing a file has some relationship to the VM system releasing its
reference (and causing the ultimate file closure.) The entire purpose
of caching is to make sure that data stays around in memory as long as
it is useful.

Interesting note from last month’s FAST conference: 30 minutes is the
“magic number” for how long data is best kept in memory rather than
retrieved from disk (this from Jim Gray, Microsoft Research). What that
means is that if you plan on using that data in the next 30 minutes,
we’d rather keep it in memory than force you to go back out to disk…

Generally at least half the memory on your Windows system is used just
for file system data cache - we really do want to avoid going back to
disk if we can help it (I have a little file system I use for testing
our file system development kit that has no backing store - reads are
satisfied with zero filling and writes are discarded. It is incredibly
fast, which is what I wanted for testing. What’s amazing is that I can
do "xcopy /s/e/v c:\windows q:" (where “q:” is my volume) and it works
- but I have no data storage, all of the data reads are satisfied from
cache.

Regards,

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

Looking forward to seeing you at the next OSR File Systems class in
Boston, MA April 24-27, 2006.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of bjorn haake
Sent: Monday, January 09, 2006 2:22 PM
To: ntfsd redirect
Subject: Re:[ntfsd] Context Management Question

I guess I am still missing something. According to the documentation, a
call
to FltReleaseContext will free the context when the ref count hits 0. I
assume you meant to pass up the info at this point?
I assume in the ctx sample, this freeing is done in the function
CtxContextCleanup. However, I set a breakpoint there, and while for a
Word
save it was hit, for other apps like Notepad it was not (not even when
closing the application). Is there another way that contexts can be torn

down (e.g. through the FilterManager)?

Thanks, bjorn

“Lyndon J Clarke” wrote in message
news:xxxxx@ntfsd…
> Bjorne
>
> I dont know of such an api. Here howeber is a suggestion. Instead of
> telling your userspace about IRP_MJ_CLOSE instyead tell your userspace

> about the context teardown.
>
> Cheers
> Lyndon
>
> “bjorn haake” wrote in message news:xxxxx@ntfsd…
>> Thanks Lyndon. I had a stupid mistake in my code which is why it
appeared
>> that the flag I had set in postwrite was cleared before the close.
>>
>> I do have an add-on question: Is there an API that gives me the ref
count
>> so I know when the last close came in? So far I have cleared my flag
in
>> the first close encountered so I won’t be sending the operation to
user
>> space multiple times. This leads to other problems and I don’t think
that
>> it’s a good approach anyway.
>>
>> Thanks, bjorn
>>
>>
>>
>> “Lyndon J Clarke” wrote in message
>> news:xxxxx@ntfsd…
>>> Bjorn
>>>
>>> You are writing a minifilter derived from ctx and minispy. The osr
>>> article on tracking state and context referecne counting is relevant
to
>>> tradtional (aka legacy) fitler drivers which for whatever reason can
not
>>> use per stream contexts; it is not relevant to mini filter drivers.
The
>>> filter management framework performs the context management (it uses
per
>>> stream contexts etc) in your behalf; part of the wonder of filter
>>> manager :slight_smile:
>>>
>>> Cheers
>>> Lyndon
>>>
>>> “bjorn haake” wrote in message
news:xxxxx@ntfsd…
>>>> Hi All,
>>>>
>>>> I am still struggling with Context Management. I have read the
article
>>>> “Tracking State and Context - Reference Counting for File System
Filter
>>>> Drivers” on the OSR web site. I also combined the ctx and minispy
>>>> sample to create a sample driver that detects file changes. I am
still
>>>> a bit lost though on the context management. I am trying to set a
few
>>>> flags in an operation, then check for those flags in the close (on
the
>>>> same stream object). I have some sample output below from a save of
a
>>>> word document. I thought the following strategy useful for word: in

>>>> PreWrite check for IRP_NOCACHE and set flag. If in rename this flag
is
>>>> set it’s not a straight rename but a word (or powerpoint or other )

>>>> save that uses renaming rather than straight writes. In the below
>>>> output, the IRP_NOCACHE is set on the streamobject with address
>>>> 0xE2E96440. When I check the rename on that same address the flag
is no
>>>> longer set and the create count is 0 again. So do I still need to
use
>>>> FsRtlInsertPerStreamContext and FsRtlRemovePerStreamContext and the

>>>> suggested algorithms in the article? Is this because streams are
>>>> different even though they have the same address (address is being
>>>> reused?) and I really need to just use the per-file context?
>>>>
>>>> Thanks, bjorn
>>>>
>>>> PS: Here’s the sample output with IRP, Counters, Flags set, stream
>>>> object address and filename.
>>>>
>>>> IRP_MJ_CLOSE Create: ‘2’
Cleanup:
>>>> ‘1’ Close: ‘1’ File Create! SO: ‘E2E96440’ File is
>>>> ‘\Device\HarddiskVolume2\testdir~WRD0000.tmp’
>>>> IRP_MJ_CLOSE Create: ‘9’
Cleanup:
>>>> ‘9’ Close: ‘8’ NOCACHE WRITE!! SO: ‘E2E96440’ File is
>>>> ‘\Device\HarddiskVolume2\testdir~WRD0000.tmp’
>>>> IRP_MJ_SET_INFORMATION Create: ‘0’
Cleanup:
>>>> ‘0’ Close: ‘0’ Temp!!! Rename from
>>>> ‘\Device\HarddiskVolume2\testdir\New Microsoft Word Document
(2).doc’
>>>> to ‘\Device\HarddiskVolume2\testdir~WRL0001.tmp’ SO: ‘E1083E48’

>>>> File is ‘\Device\HarddiskVolume2\testdir\New Microsoft Word
Document
>>>> (2).doc’
>>>> IRP_MJ_SET_INFORMATION Create: ‘0’
Cleanup:
>>>> ‘0’ Close: ‘0’ Temp!!! Rename from
>>>> ‘\Device\HarddiskVolume2\testdir~WRD0000.tmp’ to
>>>> ‘\Device\HarddiskVolume2\testdir\New Microsoft Word Document
(2).doc’
>>>> SO: ‘E2E96440’ File is
>>>> ‘\Device\HarddiskVolume2\testdir~WRD0000.tmp’
>>>> IRP_MJ_CLEANUP Create: ‘0’
Cleanup:
>>>> ‘0’ Close: ‘0’ SO: ‘E2E96440’ File is
>>>> ‘\Device\HarddiskVolume2\testdir\New Microsoft Word Document
(2).doc’
>>>> IRP_MJ_CLOSE Create: ‘17’
Cleanup:
>>>> ‘17’ Close: ‘17’ SO: ‘E2E96440’ File is
>>>> ‘\Device\HarddiskVolume2\testdir\New Microsoft Word Document
(2).doc’
>>>> IRP_MJ_CREATE Create: ‘0’
Cleanup:
>>>> ‘0’ Close: ‘0’ SO: ‘E2E96440’ File is
>>>> ‘\Device\HarddiskVolume2\testdir\New Microsoft Word Document
(2).doc’
>>>> IRP_MJ_CLEANUP Create: ‘0’
Cleanup:
>>>> ‘0’ Close: ‘0’ SO: ‘E2E96440’ File is
>>>> ‘\Device\HarddiskVolume2\testdir\New Microsoft Word Document
(2).doc’
>>>> IRP_MJ_CLOSE Create: ‘18’
Cleanup:
>>>> ‘18’ Close: ‘18’ SO: ‘E2E96440’ File is
>>>> ‘\Device\HarddiskVolume2\testdir\New Microsoft Word Document
(2).doc’
>>>> IRP_MJ_CLEANUP Create: ‘0’
Cleanup:
>>>> ‘0’ Close: ‘0’ DELETE! SO: ‘E1083E48’ File is
>>>> ‘\Device\HarddiskVolume2\testdir~WRL0001.tmp’
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>>
>
>
>


Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to xxxxx@lists.osr.com