RE: preventing recursive loop in create dispatch hand-ler

NTFSD
1

Also, I am trying to understand the need to open a file via an alternate IRP
in a creation routine. If you are getting an IRP_MJ_CREATE and the file is,
say, “c:\x.x”, why would anyone create a seperate file object, build a new
IRP and open the file “c:\x.x”? WOuld it not be better to simply let the
original IRP_MJ_CREATE go through and then perform some operation on the
file after completion?

Am I missing something?

Jamey

-----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
  1. 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>