I’m used to having something like a device extension (pdx), but under the filter manager there appears to be some system api in place to help manage context for you. My though (From reading docs) is each “instance” is a volume, so i would just have some type of device extension structure (context) that I would initialize at that time. But I see there is a FltSetInstanceContext() and a FltSetVolumeContext() so a bit confused on where am I supposed to put my data structures that are used at the volume (instance) level?
I found an old word .doc file that answer half the question about which type, but it doesn’t tell me where to create and attach it, do I do it in the init for the instance?
Contexts can be created for the following types of objects:
? Volume ? This represents a mounted device in the system.
? Instance ? This is a minifilter’s attachment to a given volume. A minifilter may attach more then once to a given volume. If a minifilter supports only once instance per volume, it is recommended that instance contexts be used instead of volume contexts because they are more efficient.
Digging deeper to that .doc file, got the other answers. I love the old style of documentation, it’s very clear, i find a lot of newer docs have a lot of text but doesn’t tell me a lot. Here’s what it said:
During the InstanceSetupCallback(), the minifilter also receives the VolumeDeviceType and the VolumeFilesystemType to help the minifilter decide whether or not it is interested in attaching to this volume. From the InstanceSetupCallback(), a minifilter can query the volume properties by calling FltGetVolumeProperties() and set a context using FltSetInstanceContext() on this instance if it plans to attach this instance to the volume. It can also open and close files on the volume.
Unfortunately it appears that really good technical doc writers are
undervalued these days…
It’s overkill and doesn’t demonstrate volume contexts, but the Ctx sample
shows the mechanics of dealing with FltMgr contexts. Not terribly difficult,
but also not intuitively obvious.
Thanks, looks like at least those shared resource inline functions would be a good thing to make standard. Complete with all the fancy compiler defines that I’d have to look up to know what it’s all about .
It is possible to have multiple instances per volume belonging to the same
filter.
I have never seen it in practice but you are allowed with your filter to
have an instance at a certain altitude and another one on the same volume
at a lower or higher altitude.
So in this case the hierarchy is Volume -> Instance and the relation is one
to many as there is one volume and many instances.
Look at the FltGetVolumeFromXXX routines. If there was a 1-1 relation you
should have the same kind of routines for instances life
FltGetInstaceFromFileObject but since it is ambiguous which instance
you want since you can have more there are no such routines. Instead you
can get an instance on a certain volume by name since they are named and
also you can enumerate instance on a volume.
Again many instances could be in theory belonging to the same filter.
Thanks, looks like at least those shared resource inline functions would
be a good thing to make standard. Complete with all the fancy compiler
defines that I’d have to look up to know what it’s all about . > > > — > NTFSD is sponsored by OSR > > > MONTHLY seminars on crash dump analysis, WDF, Windows internals and > software drivers! > Details at http: > > To unsubscribe, visit the List Server section of OSR Online at < > http://www.osronline.com/page.cfm?name=ListServer> >