Ok, but in the article, they say to check
SectionObjectPointer->ImageSectionObject and
SectionObjectPointer->DataSectionObject, and make no mention of
SharedCacheMap. Are you saying check SharedCacheMap instead? What I’m
wondering is that if both SectionObjectPointers are set to NULL by the
system before the fileobject is derefed (as is SharedCacheMap as you say),
how could the CcGetFileObjectFromSectionPtrs EVER return “this” fileobject?
That doesn’t make any sense to me if it is true that the system nulls them
before the deref. Thoughts?
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Slava Imameyev
Sent: Thursday, January 26, 2006 4:41 PM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] Legacy tracking query
Yes, it means the second.
I will try to explain a solution described in the article. But I think there
is some omission in the solution.
The idea is clear- to track a file object context which is common for all
opened instance of a data stream, but realization ( for my opinion ) has
some omissions.
The solution is based on the assumption that the System sets to NULL the
SectionObjectPointer->SharedCacheMap pointer during shared cache map
uninitialization, this is definitely true( remember- SectionObjectPointer is
common for all file objects which represent the same data stream ).
If the above assumption is true then the check (
CcGetFileObjectFromSectionPtrs( FileObject->SectionObjectPointer ) !=
FileObject ) is always true because the cache map uninitialization is
performed before IRP_MJ_CLOSE will be sent, because
SectionObjectPointer->SharedCacheMap->FileObject is dereferenced during
shared cache map uninitialization ( file object is referenced during a
shared cache map creation ), therefore IRP_MJ_CLOSE for a
SectionObjectPointer->SharedCacheMap->FileObject is sent only after
SectionObjectPointer->SharedCacheMap->shared
cache map uninitialization( i.e. zeroing the
SectionObjectPointer->SharedCacheMap pointer ) .
In addition - FO_STREAM_FILE flag is checked because for a stream file
object an IRP_MJ_CREATE request is not sent.
“Matthew N. White” wrote in message news:xxxxx@ntfsd…
> Hi,
>
> Can anyone explain a particular point in the OSR context tracking article:
> http://www.osronline.com/article.cfm?article=102
>
> When describing a simplified algorithm for filters only caring about data
> operations, it says this in one of the bullets:
>
> “For each IRP_MJ_CLOSE the filter driver decrements the reference count on
> the per-file context structure if the FO_STREAM_FILE bit is not set for
> the
> file object and if CcGetFileObjectFromSectionPtrs does not return this
> file
> object.”
>
> First of all, in the close path, does this mean do this:
>
> if( ( !IsStreamFile ) ||
> ( CcGetFileObjectFromSectionPtrs( FileObject->SectionObjectPointer
> ) != FileObject ) ){
>
> /* do decrement on context /
>
> }
>
> Or this:
>
> if( ( !IsStreamFile ) &&
> ( CcGetFileObjectFromSectionPtrs( FileObject->SectionObjectPointer
> ) != FileObject ) ){
>
> / do decrement on context */
>
> }
>
> I’m assuming it means the second, but I think it could be interpreted
> either
> way.
>
> Secondly, when would a filter EVER see a close operation on a fileobject
> that CcGetFileObjectFromSectionPtrs identifies as being this file object?
> Would this be when the MM derefs it FO reference when purging the
> cachemap,
> for example? I’m just trying to understand the need for that bit of
> logic.
>
> Thanks,
> Matt
>
>
>
>
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@bitarmor.com
To unsubscribe send a blank email to xxxxx@lists.osr.com