RE: preventing recursive loop in create dispatch hand--ler

NTFSD
1

I’m an ENCRYPTING driver.

I think this method is correct enough because of this:
At every (filter) level things should happen followingly:

  1. I’m always requesting the next lower driver to do its functionality
    which is opaque to me - it should rely on the generic FSD interface.
  2. I’m always maintaining my (level) functionality to all callers of me.
    My functionality is hence opaque to them as far as I maintain
    generic FSD interface correctly.

Paul

PS: I think this method should work properly even in the case of
multiple layered encrypting filters.

-----P?vodn? zpr?va-----
Od: Jamey Kirby [SMTP:xxxxx@storagecraft.com]
Odesl?no: 19. ?ervence 2000 19:08
Komu: File Systems Developers
P?edm?t: [ntfsd] RE: preventing recursive loop in create dispatch
hand ler

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
> ler
>
>
> I 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:
>
> 1. 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).
>
> 2. 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
>
> 3. 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>>
> >
> >
>
>
> —
> You are currently subscribed to ntfsd as: xxxxx@sodatsw.cz
> To unsubscribe send a blank email to $subst(‘Email.Unsub’)</apisup.c>