question regarding the OSR article -- Filtering the Riff-Raff

NTFSD
1

I was reading this NT Insider article and I have a question on this
paragraph at the end of the article.

== snip
This specific behavior is actually quite common for NTFS, because NTFS
routinely creates its own internal file objects. If those file
objects are, in turn, used for backing the section object, all
subsequent paging I/O operations will be done against that file
object. If a file system filter driver does not track this file
object (because it never observed the IRP_MJ_CREATE) then it will not
properly handle this I/O!
== end of snip

It says the file object used to back the SectionObjects could be the
one created internally by NTFS for which I might not see an
IRP_MJ_CREATE? Is this correct? How do I track creation of such file
objects in my filter driver?

Thanks

2

It is correct. In the extreme case you could see the section object
backed by one stream file object and the cache maps backed by a
different stream file object.

First, you need to decide if you even NEED to detect it. At this point,
if you can restrict yourself to the latest W2K version (notably hot fix)
then you can just use filter contexts. If that doesn’t work for you, go
back and read the articles about reference counting.

Regards,

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of NTFSD-List
Sent: Friday, May 06, 2005 9:15 PM
To: ntfsd redirect
Subject: [ntfsd] question regarding the OSR article – Filtering the
Riff-Raff

I was reading this NT Insider article and I have a question on this
paragraph at the end of the article.

== snip
This specific behavior is actually quite common for NTFS, because NTFS
routinely creates its own internal file objects. If those file
objects are, in turn, used for backing the section object, all
subsequent paging I/O operations will be done against that file
object. If a file system filter driver does not track this file
object (because it never observed the IRP_MJ_CREATE) then it will not
properly handle this I/O!
== end of snip

It says the file object used to back the SectionObjects could be the
one created internally by NTFS for which I might not see an
IRP_MJ_CREATE? Is this correct? How do I track creation of such file
objects in my filter driver?

Thanks

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

You are currently subscribed to ntfsd as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com