What happens in the case where there may be a critical filter above you;
i.e. an encryption driver? Isn’t it possible to miss some critical
functionality by directly calling lower FSD driver without entering the top
of the stack?
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Pavel Hrdina
Sent: Wednesday, July 19, 2000 9:51 AM
To: File Systems Developers
Subject: [ntfsd] RE: preventing recursive loop in create dispatch hand
lerI think the Geoff Clow is nearest to the TRUTH.
It is neccessary to disassemble some parts of NTOS to
definitely understand some interactions between components.I have used the following techniques:
I am using no Io Manager’s and Memory Manager’s ZwXxxx routines
inside the FSD filter. I use them only from some system thread where
I know I’m the Request Iniciator (mostly in Nt variant,
because there is
evident the Thread->PreviousMode is KernelMode and thus the mechanism
for system calls [int 2e] is not needed at all).For every mounted volume there is in our VCB:
a) Physical device (named, eg. \Device\Harddisk0\Partition5)
b) FSD device (mostly unnamed)
c) Next lower device
- to NextLowerDevice we will forward all requests
- if we are attached right to FSD device, these two will be the same
- for network redirectors the Physical device and FSD device
are the same
eg. \Device\LanmanRedirector
- If I want to open the file, query or set some info on it:
I have written some synchronous routines like a NtCreateFile,
NtQueryInformationFile and NtSetInformation file. Each of
it builds an IRP and sends it down to the Vcb->NextLowerDevice.
Thus I’m always calling all the filter stack below me, but no
filter above me gets called.I am appending the file APISUP.C which contains these routines and
mechanisms I’m using. (Hardest routine to implement is Create and
currently I know some of its disadvantages - base methods are taken
from the IopParseDevice routine)Paul
> <<apisup.c>>
>
></apisup.c>