Nicholas,
You should implement an upper volume filter driver. The best way to
create such a driver is to base it off of the Windows XP DDK’s Toaster
Filter sample. This driver’s source is intended to be used for both W2K
and XP drivers, so use the W2K DDK to build it and the same image will
work on W2K+. Do not use the W2K DDK Toaster Filter sample as it has
bugs. Without any modifications the XP DDK Toaster Filter sample is a
functional volume (and disk) filter driver. It will filter both basic
and dynamic disks. All you need to do is to add your driver’s name to
the UpperFilters or LowerFilters value of the class of devices that you
wish to filter (as Diskperf does). Oh, and you need to make sure that
its service key contains the following values (you can change
ErrorControl if you like):
Value Name Data Type Data
Group REG_SZ Pnp Filter
Start REG_DWORD 0
Type REG_DWORD 1
ErrorControl REG_DWORD 1
There’s one more gotcha. If you want to provide persistent services
from boot to boot, you’ll soon find that the volume does not have a
unique volume name at the time your AddDevice() routine is called (I’m
talking about the kind of unique volume names that get returned by the
Win32 call GetVolumeNameForVolumeMountPoint()). Frankly I think it’s an
architectural bobo that the device has no name when it’s created - it
makes providing persistent services awkward. However, the mount manager
does name volumes shortly after their creation (and as far as I
remember, before any meaningful symbolic links are created - meaning
that no I/O has hit the volume, at least from user mode) by sending
IOCTL_MOUNTDEV_LINK_CREATED to the volume (it’s actually sending it to
the volume device interface, but luckily for us this is the same device
object as the volume itself) and when you receive this IOCTL you can
parse out the unique volume name and recommence whatever services you
were providing on the previous boot before forwarding this IOCTL on to
the volume class driver (or whoever is filtering below you).
If you need to filter volumes for NT4 it’s a different story. Let me
know and I’ll provide more details.
Nate Bushman
PowerQuest Corp.
-----Original Message-----
From: Nicholas Kidd [mailto:kidd@cs.wisc.edu]
Sent: Thursday, November 21, 2002 4:00 PM
To: File Systems Developers
Subject: [ntfsd] filter driver location question
Hello,
I am wanting to develop a filter driver that will see all traffic sent
from NTFS to disk. Using the wonderful tool DeviceTree, I see that
the drivers Diskperf and PartMgr are attached to the Disk driver.
Looking in the registry with regedt32, it appears that these drivers
are Upper class filter drivers. I was wondering if this is the
correct place to attach my filter? Or would it be better to be a
lower filter driver on the MED device that NTFS is attached to? In
all honesty, I would like an instance of my filter per NTFS partition.
This is why I was thinking of making a lower filter attached (in some
way) to NTFS. Ok, a few more questions:
Is there any online references on what parts of the driver should/can
be in paged and non paged memory? I was reading filter.c for the
toaster example with the Win2k ddk and that example had PAGED(); in
most of the functions.
Are the #pragma statements necessary for driver writing? If so, is
there any online documentation about what the different “pragmas” are?
Thanks,
-Nick Kidd
ps. I know there are many books on these subjects, but being a student
I
am trying to not go out and buy them. Hence the request for online
references 
You are currently subscribed to ntfsd as: xxxxx@powerquest.com
To unsubscribe send a blank email to %%email.unsub%%