Filter Manager Stream Context vs XP/W2K2 Per Stream Context

XP and W2K3 introduced Per Stream Context to associate a context with a file
stream. With PSC a call back occurred when the underlying FsContext
structure was being deleted to indicate time to delete/cleanup the PSC.

With the Mini Filter, is there something analogous? Or will the FsContext
(or whatever a PSC is tied to) not be deleted until the mini filter does a
FltReleaseContext or FltDeleteContext. I see there is a callback for when
context are being deleted, but with Instance context they never get deleted
unless I first release or delete them.

Ken

The Filter Manager implements the StreamContexts using the
PerStreamContext support which the file systems provide.

When your StreamContext is associate with a stream
(FltSetStreamContext()), a reference is added. When the file system is
ready to teardown its stream data structures, it calls the Filter
Manager to say it is being deleted. At this point, the Filter Manager
will remove the reference on your StreamContext (as it is now unlinked
from the stream object), but Filter Manager will not call your
registered context delete routine until all the references to your
StreamContext are released. Typically, this reference is the last
reference on your stream context, so you will receive your context
teardown at this time. If you do some sort of asynchronous processing
of your stream contexts, you may have an outstanding reference on your
StreamContext, therefore the context teardown callback will be delayed
until all those references are released.

Getting to the point where the reference count on your StreamContext is
0 should not require you to call FltDeleteContext(). Just make sure
that for every FltGetStreamContext() your filter calls, you call
FltReleaseContext() to release the reference.

You only need to call FltDeleteContext() when you need to remove the
link between your context and the object *before* the object’s lifetime
is ended by the system. It is very likely that you never need to call
FltDeleteContext() in your filter – it was added more for completeness
sake rather than to address a common functional need.

Molly Brown
Microsoft Corporation

This posting is provided “AS IS” with no warranties and confers no
rights.


From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ken Galipeau
Sent: Friday, March 05, 2004 1:47 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] Filter Manager Stream Context vs XP/W2K2 Per Stream
Context

XP and W2K3 introduced Per Stream Context to associate a context with a
file stream. With PSC a call back occurred when the underlying FsContext
structure was being deleted to indicate time to delete/cleanup the PSC.

With the Mini Filter, is there something analogous? Or will the
FsContext (or whatever a PSC is tied to) not be deleted until the mini
filter does a FltReleaseContext or FltDeleteContext. I see there is a
callback for when context are being deleted, but with Instance context
they never get deleted unless I first release or delete them.

Ken


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

You are currently subscribed to ntfsd as: xxxxx@windows.microsoft.com

To unsubscribe send a blank email to xxxxx@lists.osr.com

Ken,

Instance contexts will not get deleted unless you’re your filter is
unloaded, the volume is dismounted, or a specific request is made to
detach your filter from the given volume.

If you are not seeing the delete in one of these cases it is because you
are not properly dereferencing the context.

I want to make this clear for everyone. It is very rare for a filter to
need to call FltReferenceContext(). The system does all the proper
referencing for you when you “get” a context. This was only added for
completeness.

As Molly has already pointed out, if you used a chk’d version of filter
manager (which I would recommend during development) if you unload your
filter leaked contexts will be reported on the debugger screen.

Neal Christiansen

Microsoft File System Filter Group Lead
This posting is provided “AS IS” with no warranties, and confers no
rights.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Molly Brown
Sent: Monday, March 08, 2004 11:02 AM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] Filter Manager Stream Context vs XP/W2K2 Per Stream
Context

The Filter Manager implements the StreamContexts using the
PerStreamContext support which the file systems provide.

When your StreamContext is associate with a stream
(FltSetStreamContext()), a reference is added. When the file system is
ready to teardown its stream data structures, it calls the Filter
Manager to say it is being deleted. At this point, the Filter Manager
will remove the reference on your StreamContext (as it is now unlinked
from the stream object), but Filter Manager will not call your
registered context delete routine until all the references to your
StreamContext are released. Typically, this reference is the last
reference on your stream context, so you will receive your context
teardown at this time. If you do some sort of asynchronous processing
of your stream contexts, you may have an outstanding reference on your
StreamContext, therefore the context teardown callback will be delayed
until all those references are released.

Getting to the point where the reference count on your StreamContext is
0 should not require you to call FltDeleteContext(). Just make sure
that for every FltGetStreamContext() your filter calls, you call
FltReleaseContext() to release the reference.

You only need to call FltDeleteContext() when you need to remove the
link between your context and the object *before* the object’s lifetime
is ended by the system. It is very likely that you never need to call
FltDeleteContext() in your filter – it was added more for completeness
sake rather than to address a common functional need.

Molly Brown
Microsoft Corporation

This posting is provided “AS IS” with no warranties and confers no
rights.


From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ken Galipeau
Sent: Friday, March 05, 2004 1:47 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] Filter Manager Stream Context vs XP/W2K2 Per Stream
Context

XP and W2K3 introduced Per Stream Context to associate a context with a
file stream. With PSC a call back occurred when the underlying FsContext
structure was being deleted to indicate time to delete/cleanup the PSC.

With the Mini Filter, is there something analogous? Or will the
FsContext (or whatever a PSC is tied to) not be deleted until the mini
filter does a FltReleaseContext or FltDeleteContext. I see there is a
callback for when context are being deleted, but with Instance context
they never get deleted unless I first release or delete them.

Ken


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

You are currently subscribed to ntfsd as: xxxxx@windows.microsoft.com

To unsubscribe send a blank email to xxxxx@lists.osr.com


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

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

Neal,

Then I do understand the following about Contexts, please correct me if
I am mistaken.
The rules to consider a Context as properly cleanup are two:

  1. #FltAllocate(=1) + #FltGetXxxContext + #FltReferenceContext =
    #FltReleaseContext
  2. #FltSetXxxContext(see note) = #FltDeleteXxxContext(see note) +
    #FilterManager_Delete(=0 or 1) (on object deletion or filter unload).

We must be aware that if we are not done with a Context then we must be
sure that the two previous rules are not true at the same moment
accidentally. Obviously we must NOT call FltAllocate, FltReleaseContext
due to doing that will free the Context.

And we must never allow to happen a state in which it is certain some of
the two conditions:

A) #FltReleaseContext > #FltAllocate(=1) + #FltGetXxxContext +
#FltReferenceContext
B) #FltDeleteXxxContext + #FilterManager_Delete(=0 or 1) >
#FltSetXxxContext.

For example it’s NOT OK to call FltAllocate, FltSetXxxContext,
FltReleaseContext, FltReleaseContext, … FltAnyThing …

Then for example this sequence is perfectly correct:

FunctionName (# of references after the call, rules that are
false)

  • FltAllocate (1, 1),
  • FltSetXxxContext (2, 1-2),
  • FltReleaseContext (1, 2),
    * Any pair of Reference Vs Release (that is #FltGetXxxContext +
    #FltReferenceContext = #FltReleaseContext)
  • FltGetXxxContext (2, 1-2),
  • FltDeleteXxxContext (1, 1),
  • FltSetXxxContext (2, 1-2),
  • FltReleaseContext (1, 2),

Now there is a reference. The one Filter manager will decrement during
the object deletion or filter unload.

Finally we have that mini-filter’s context cleanup callback will be
called when:

#FltAllocate + #FltSetXxxContext + #FltGetXxxContext +
#FltReferenceContext >= #FltReleaseContext + #FltDeleteXxxContext +
#FilterManager_Delete changes from >= to be ==.

(*)Note: It must be considered that FltSetXxxContext and
FltDeleteXxxContext can have an implicit FltGetXxxContext for which we
need to do FltReleaseContext.

Ramon Royo

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]
Sent: Wednesday, March 10, 2004 8:28 AM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] Filter Manager Stream Context vs XP/W2K2 Per Stream
Context

Ken,

Instance contexts will not get deleted unless you’re your filter is
unloaded, the volume is dismounted, or a specific request is made to
detach your filter from the given volume.

If you are not seeing the delete in one of these cases it is because you
are not properly dereferencing the context.

I want to make this clear for everyone. It is very rare for a filter to
need to call FltReferenceContext(). The system does all the proper
referencing for you when you “get” a context. This was only added for
completeness.

As Molly has already pointed out, if you used a chk’d version of filter
manager (which I would recommend during development) if you unload your
filter leaked contexts will be reported on the debugger screen.

Neal Christiansen

Microsoft File System Filter Group Lead
This posting is provided “AS IS” with no warranties, and confers no
rights.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Molly Brown
Sent: Monday, March 08, 2004 11:02 AM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] Filter Manager Stream Context vs XP/W2K2 Per Stream
Context

The Filter Manager implements the StreamContexts using the
PerStreamContext support which the file systems provide.

When your StreamContext is associate with a stream
(FltSetStreamContext()), a reference is added. When the file system is
ready to teardown its stream data structures, it calls the Filter
Manager to say it is being deleted. At this point, the Filter Manager
will remove the reference on your StreamContext (as it is now unlinked
from the stream object), but Filter Manager will not call your
registered context delete routine until all the references to your
StreamContext are released. Typically, this reference is the last
reference on your stream context, so you will receive your context
teardown at this time. If you do some sort of asynchronous processing
of your stream contexts, you may have an outstanding reference on your
StreamContext, therefore the context teardown callback will be delayed
until all those references are released.

Getting to the point where the reference count on your StreamContext is
0 should not require you to call FltDeleteContext(). Just make sure
that for every FltGetStreamContext() your filter calls, you call
FltReleaseContext() to release the reference.

You only need to call FltDeleteContext() when you need to remove the
link between your context and the object *before* the object’s lifetime
is ended by the system. It is very likely that you never need to call
FltDeleteContext() in your filter – it was added more for completeness
sake rather than to address a common functional need.

Molly Brown
Microsoft Corporation

This posting is provided “AS IS” with no warranties and confers no
rights.


From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ken Galipeau
Sent: Friday, March 05, 2004 1:47 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] Filter Manager Stream Context vs XP/W2K2 Per Stream
Context

XP and W2K3 introduced Per Stream Context to associate a context with a
file stream. With PSC a call back occurred when the underlying FsContext
structure was being deleted to indicate time to delete/cleanup the PSC.

With the Mini Filter, is there something analogous? Or will the
FsContext (or whatever a PSC is tied to) not be deleted until the mini
filter does a FltReleaseContext or FltDeleteContext. I see there is a
callback for when context are being deleted, but with Instance context
they never get deleted unless I first release or delete them.

Ken


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

You are currently subscribed to ntfsd as: xxxxx@windows.microsoft.com

To unsubscribe send a blank email to xxxxx@lists.osr.com


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

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


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

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