There are 6 context types are named in DDK:
FLT_FILE_CONTEXT
FLT_INSTANCE_CONTEXT
FLT_STREAM_CONTEXT
FLT_STREAMHANDLE_CONTEXT
FLT_TRANSACTION_CONTEXT
FLT_VOLUME_CONTEXT
2 of them are used from Vista only…
Unfortunately I have not found good description about situation of using this contexts in OSR too.
Can somebody comment it?
I’m looking for description
> Unfortunately I have not found good description about situation of using
this contexts in OSR too.
You astonish me.
To start with you need to understand that a context is a lump of memory
which is associated with and object and your filter. So, at least
notionally you call one of the FltGetXXXContexts giving it the object and
info about your filter and you get back the correct context.
So, what sort of objects can be associated:
FLT_VOLUME_CONTEXT
This is associate with the “volume”. In the case of a physical media you
get one volume object (and hence volume context) for every “physical” media
(so,one for c:\ one for d:\ and so on). In the network case you get one per
network connector (so one for x:, y: & z: if they where connected via SMB
and a different one for q: if it was connected via WebDav).
FLT_INSTANCE_CONTEXT
You can arrange to filter each volume more than once. In that case every
time you filter the volume you get a new *instance* and so you can associate
an instance context with it. In the majority of cases you will only have
one instance per volume and so you may find people use either the instance
context or the volume context.
FLT_FILE_CONTEXT
This is associate with non closed files. For as long as *anyone* has a file
open the context stays around. If an application opens a file 30 times,
there will still be only one file context. Note that because of the way
that caching works file contexts (and stream and stream handle contexts) can
hang around long after the last application has closed the last handle to
it. But they do not last forever. This is a new construct and you might
want to be careful before using it since some file systems may not support
it even in Vista and non do before.
FLT_STREAM_CONTEXT
This is associate with non closed streams. Remember that in NTFS a file can
have multiple streams (c:\a and c:\a:other are two streams on the same file
(‘a’). If an application opens a stream 30 times, there will still be only
one stream context.
FLT_STREAMHANDLE_CONTEXT
This is associated with a specific instance of an open stream.
Specifically it is associated with a FileObject (the data structure that NT
uses to deal with open instances. If a file opens a file 10 times then
there will be 10 stream handle contexts. There is an edge case to do with
inherited handles, but you can ignore it for now
Note that many streamhandle context can exist for the stream for which there
will be only one streamcontext.
Equally many stream contexts can exist for the file for which there will be
only one file context.
And many file contexts can exist for an instance for which there will be
only one instance context.
And finally many instance contexts may exist for the volume for which there
will only be one volume context
So, if you like there is a level of granularity associated with the type of
context.
FLT_TRANSACTION_CONTEXT
This is somewhat orthogonal since transactions are orthogonal to file and
volumes (and indeed have an existence beyond filesystems). When a
transaction is create you associate a context with it. Whenever you see
that transaction again you can get that context back.
–
Rod Widdowson
Consulting Partner
Steading System Software LLP
+44 1368 850217 +1 508 915 4790
wrote in message news:xxxxx@ntfsd…
> There are 6 context types are named in DDK:
> FLT_FILE_CONTEXT
> FLT_INSTANCE_CONTEXT
> FLT_STREAM_CONTEXT
> FLT_STREAMHANDLE_CONTEXT
> FLT_TRANSACTION_CONTEXT
> FLT_VOLUME_CONTEXT
>
> 2 of them are used from Vista only…
>
> Unfortunately I have not found good description about situation of using
> this contexts in OSR too.
>
> Can somebody comment it?
>
>
>
> I’m looking for description
>
Rod,
thanks a lot!
Good description, it wold e reasonable for Microsoft make it part of DDK. 
But some questions remains…
For example, FLT_VOLUME_CONTEXT for network.
Which context will be for \Server\Share?
If device q: has same assign, the context will be the same?
If assign is done on its part \Server\Share\dir1.…\dirn, they have same context too?
The same question for SUBST assigning…
> For example, FLT_VOLUME_CONTEXT for network.
Which context will be for \Server\Share?
If device q: has same assign, the context will be the same?
If assign is done on its part \Server\Share\dir1.…\dirn, they have same
context too?
It’s been too long since I looked so do the test but I know that
\Server\Share will get the same volume context no matter how you get at it.
(via q: or via \server\share).
What I’m not certain (but am pretty sure) about is that you’ll get the same
volume for \OtherServer\Share as well. This is because the volume is
associated with the \Device\Lanman\Redirector in XP and \Device\MUP in
Vista. FltParseFileNameInformation provides you with the tools you need to
get out of that hole - [but beware that there are tygers awaiting you if you
start making too many assumption about the file names over the network]
But the easiest thing is to run an experiment. If the answer seems odd ask
in here.
Ok,
Rod,
if so, I know the answer, I have experience for network for full filter and I guess there is the same.
Driver has not information about net assignment and receive ALL names in format {symbolik_link}\Server\Share\Dir…
Rod, other question for you.
Or probably I open other thread.
How to filtering I/O requests coming via Network?
Or other, is it possible define PID which initiated I/O request?