Hi,
I wonder if one of you kind souls can help me. I am using the file tracking
method documented in the NT Insider to track certain files under XP. I’m
only interested in user I/O so I am using the simpler algorithm. The problem
I have is that I seem to be seeing one extra IRP_MJ_CREATE for each file
that never gets an associated IRP_MJ_CLOSE so my reference count never
reaches zero. The extra create is the first one I see. The only thing in the
least unusual about it is that the flag SL_FORCE_ACCESS_CHECK is set in the
stack flags and this is the only request that seems to have it set.
I’m sure it is something really stupid but I’m at that point where I can’t
see the wood for the trees.
Any ideas would be much appreciated,
Kind Regards,
Trevor.
MJ_CLOSE is sent much later, maybe hours later. It is sent when the Cache
Manager will decide to kill the cache map associated with the file.
Track MJ_CLEANUP instead.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
----- Original Message -----
From: “Trevor Heartfield”
Newsgroups: ntfsd
To: “Windows File Systems Devs Interest List”
Sent: Wednesday, July 21, 2004 7:42 PM
Subject: [ntfsd] I’m having a slight problem with file tracking (the OSR simple
method) - help would be appreciated
> Hi,
> I wonder if one of you kind souls can help me. I am using the file tracking
> method documented in the NT Insider to track certain files under XP. I’m
> only interested in user I/O so I am using the simpler algorithm. The problem
> I have is that I seem to be seeing one extra IRP_MJ_CREATE for each file
> that never gets an associated IRP_MJ_CLOSE so my reference count never
> reaches zero. The extra create is the first one I see. The only thing in the
> least unusual about it is that the flag SL_FORCE_ACCESS_CHECK is set in the
> stack flags and this is the only request that seems to have it set.
>
> I’m sure it is something really stupid but I’m at that point where I can’t
> see the wood for the trees.
>
> Any ideas would be much appreciated,
> Kind Regards,
> Trevor.
>
>
>
> —
> Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
You can wait an age after IRP_MJ_CLEANUP for that IRP_MJ_CLOSE. If cc/vm
hold a reference to the file object that reference can be held for a very
long time indeed and IRP_MJ_CLOSE is not sent until that reference is
relased. I assume you *do* see IRP_MJ_CLEANUP for this file object? If you
are not at all interested in paging i/o then you can count the IRP_MJ_CREATE
and the IRP_MJ_CLEANUP; when the number of cleanup becomes equal to the
number of create you can terminate your tracking for the thing. If you are
interested in paging i/o then you need to count the IRP_MJ_CLOSE as well as
the other bits and pieces described in the nt insider article.
If you are interested in XP and later but not earlier then you could
consider using the stream contexts introduced in XP. I trust you are aware
of the ‘soon to arrive in XP’ filter manager model for mini filters?
“Trevor Heartfield” wrote in message
news:xxxxx@ntfsd…
> Hi,
> I wonder if one of you kind souls can help me. I am using the file
tracking
> method documented in the NT Insider to track certain files under XP. I’m
> only interested in user I/O so I am using the simpler algorithm. The
problem
> I have is that I seem to be seeing one extra IRP_MJ_CREATE for each file
> that never gets an associated IRP_MJ_CLOSE so my reference count never
> reaches zero. The extra create is the first one I see. The only thing in
the
> least unusual about it is that the flag SL_FORCE_ACCESS_CHECK is set in
the
> stack flags and this is the only request that seems to have it set.
>
> I’m sure it is something really stupid but I’m at that point where I can’t
> see the wood for the trees.
>
> Any ideas would be much appreciated,
> Kind Regards,
> Trevor.
>
>
>