Yes, I got it working now -- Thanks for the help, again.
What I was seeing happened if I forced the stream context ref count to 0
while it was still "set" on the stream. You way you describe is so much
easier. I like this stuff!!!
/ted
-----Original Message-----
From: Neal Christiansen [mailto:xxxxx@windows.microsoft.com]
Sent: Wednesday, March 10, 2004 1:33 AM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] Filter Manager - FltGetStreamContext returning "stale"
data
Ted,
The filter manager does not return stale contexts which have been freed. I
believe this is occurring because you are doing your own ref counting.
Do not do your own ref counting, there is no need. The filter manager will
do this for you. It properly manages context lifetime.
In post-create it is reasonable to call GetStreamContext to see if one
already exists. If not, create your own and call set with "keepIfExists"
and specify and "old" value so you can get the one that got set. If you get
back an old value, do not ref it, just release it when you are done. Note
that you do need to release the context that failed to be set so it will be
freed.
Then whenever you get the context simply release it when you are done. When
the stream actually goes away the context will be properly deleted from the
system and your cleanup routine will be called.
Please try this and see if it doesn't work fine for you.
If you still have an issue I will need you to send me a test filter that
demonstrates your problem along with the source and I will take a look.
Neal
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ted Hess
Sent: Tuesday, March 02, 2004 10:07 AM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] Filter Manager - FltGetStreamContext returning "stale" data
I'm not at all sure where the following problem exists - however, it appears
as if the Filter Manager function FltGetStreamContext() returns context data
that allegedly has been "freed". I think it to be freed because my Context
Cleanup Callback has been invoked.
A quick outline of what is happening: In my PostCreate routine I call
FltGetStreamContext() to see if I am already tracking the stream. If it
fails, I allocate a new context and call FltSetStreamContext. If I get a
returned context, I increment its refcount (FltReferenceContext). In my
PostClose processing, I call FltReleaseContext(streamContext) for every
FileObject I am tracking (I am also creating StreamHandle Contexts for each
FileObject I am tracking). When my refcount on the stream goes to zero, I
see my ContextCleanupCallback invoked as expected. On the next PostCreate
call (same directory), FltGetStreamContext returns me the context I have
just reset! From the looks of it, the Filter Manager ref count is now 1
this should not be!
At first I saw crashes in FltGetStreamContext and I thought it was just a
simple race between CREATE and CLOSE processing of the contexts, so I added
some serialization around the FltGetStreamContext/context creation in CREATE
and the FltReleaseContext calls in CLOSE. This did stop the crashes in the
FltGetStreamContext. The only problem is the return of the "stale" context
that my driver believes has been freed!!!
Is this a known problem/deficiency in the Filter Manager or am I totally
incorrect in my attempt to track open contexts?
Need more info?
/ted
Questions? First check the IFS FAQ at
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
You are currently subscribed to ntfsd as: xxxxx@livevault.com To unsubscribe
send a blank email to xxxxx@lists.osr.com