Smith !
As I noted a few minutes ago, you need not to have any headaches
from IRP_MJ_CREATE request.
This dispatch routine is (and always will be) inherently synchronous,
so you needn’t divide the processing into the dispatch entry itself
and to the completion routine. All you need to be done you can do
in the dispatch entry point. And the completion routine you can use
only to keep the IRP alive after some next lower driver calls
IoCompleteRequest.
Do you understand this ?
Paul
-----P?vodn? zpr?va-----
Od: Smith, Joel [SMTP:xxxxx@ntpsoftware.com]
Odesl?no: 19. ?ervence 2000 19:49
Komu: File Systems Developers
P?edm?t: [ntfsd] RE: preventing recursive loop in create dispatch
hand lerJamey,
In my case, I need to ascertain some data that may be changed by
the FSD’s handling of the create. In my case, I need to know the file’s
logical size, and a create may change that size (if it is an overwrite or
a supercede).I liked your idea of removing the disposition from the create
options, letting the nuetered create pass through, getting the size from a
completion routine, forcing the file closed again (in the completion
routine, and then resending the create. I couldn’t get this to work,
though, and instead of trying to figure out why (as a newbie to kernel
programming this stuff is incredibly difficult and time consuming for me),
I came up with a different approach to my *original* problem which had led
me to the recursion problem (and so don’t need to solve the recursion
problem anymore).I’m still curious where I misinterpreted your approach, through.
Basically, here’s what i was doing:-In IRP_MJ_CREATE if the create options indicated an overwrite or
supercede, I would change the dispostion to open or open_if. Then I would
send the irp through to the next device on the stack.-in the IRP_MJ_CREATE completion routine, I would query for the size on
the now open file. Then I would force the file close . Still in the
completion routine, I would restore the original disposition, and resend
the IRP to the next device using IoCallDriver. This resending of the IRP
sounds like a bad idea (just intuition), but it seemed to be what your
idea was saying to do, so I tried it. When it didn’t work, I just
shrugged and gave up, assuming I misinterpreted your recommendation or
there was some critical ‘clean up the irp’ step I missed (and would have
no hope of figuring out unaided in any reasonable time frame).Where did I go wrong?
-----Original Message-----
From: Jamey Kirby [mailto:xxxxx]
> Sent: Wednesday, July 19, 2000 1:19 PM
> To: File Systems Developers
> Subject: [ntfsd] RE: preventing recursive loop in create dispatch hand
> ler
>
>
> 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]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@ntpsoftware.com
> To unsubscribe send a blank email to $subst(‘Email.Unsub’)
></apisup.c></mailto:xxxxx></mailto:xxxxx>