Hi All,
I am having some problems with my file tracking code. As far as I know it
is being done correctly
i.e.
Roughly my remove looks like this:
RemoveEntry
{
If( !stream file object ) {
decrement refcount
}
If( refcount > 0 )
{
don’t remove context data and return
}
if( fileobject->sectionobjectptrs &&
( fileobject->sectionobjectptrs->ImageSectionObject != NULL ||
fileobject->sectionobjectptrs->DataSectionObject != NULL ) )
{
system still referencing this file so don`t delete context
and return
}
remove entry
}
This routine is called in the IRP_MJ_CLOSE dispatch handler of the driver.
Now this works great
Until you run my test program (basically it does lots of different types of
file access) and select
The memory map tests.
It would appear that either the fscontext is being re-used or the data is
not being removed when it should.
Does this code look ok? Any thoughts?
Ben Curley
Software Engineer
Data Encryption Systems Ltd.
Tel: +44 (0)1823 352357 (Main)
Tel: +44 (0)1823 358320 (Direct Dial)
Web: http://www.deslock.com
wrote in message news:xxxxx@ntfsd…
>
>
> I am having some problems with my file tracking code. As far as I know it
> is being done correctly
>
(Gad! Am I trying to answer yet ANOTHER file systems question?)
The only issue that I can see (and this is really a guess) is this won’t
necessarily work in the case where a stream file object is used, but no data
has been accessed. In other words, this code depends on the section object
pointers being NULL to indicate the final close… s’pose there’s a
remaining stream file object for the file that hasn’t been used for data
access…
Peter
OSR
It’s from the NT Insider - if it doesn’t work, fix it:-)))
Are you tracking EACH and EVERY file object with the FsContext? Or just
reference counting?
Regards, Dejan.
Peter Viscarola wrote:
wrote in message news:xxxxx@ntfsd…
> >
> >
> > I am having some problems with my file tracking code. As far as I know it
> > is being done correctly
> >
>
> (Gad! Am I trying to answer yet ANOTHER file systems question?)
>
> The only issue that I can see (and this is really a guess) is this won’t
> necessarily work in the case where a stream file object is used, but no data
> has been accessed. In other words, this code depends on the section object
> pointers being NULL to indicate the final close… s’pose there’s a
> remaining stream file object for the file that hasn’t been used for data
> access…
>
> Peter
> OSR
>
> —
> You are currently subscribed to ntfsd as: xxxxx@alfasp.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
–
Kind regards, Dejan M. MVP for DDK
http://www.alfasp.com E-mail: xxxxx@alfasp.com
Alfa Transparent File Encryptor - Transparent file encryption services.
Alfa File Protector - File protection and hiding library for Win32 developers.
Alfa File Monitor - File monitoring library for Win32 developers.