RE: preventing recursive loop in create dispatch hand-ler

NTFSD
1

I am also a little confused to why you would want to call ZwCreateFile() in
a drivers IRP_MJ_CREATE routine. If you need to access the file, simply pass
the original call along and in the IRP_MJ_CREATE completion routine, access
the file as you wanted.

If you need to close the file (i.e. you do not really want the IRP_MJ_CREATE
to open the file), there is an undocumented kernel API that will let you
close the file via the file object in the completion handler; dereferencing
the FO will also work.

Jamey

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Jerome Christatos
Sent: Friday, July 14, 2000 4:12 PM
To: File Systems Developers
Subject: [ntfsd] RE: preventing recursive loop in create dispatch hand
ler

Sara,

Sara Abraham wrote:

> Thanks Tony, yes this all makes sense.
>
> I think that there is another way that might be simpler than the ones
> mentioned:
> If the filter issues a ZwCreateFile() that it wants to later
recognize, it
> first issues an IoAllocateIrp() (dummy IRP which the filter
will be able to
> identify) followed by a IoEnqueueIrp() ( which will queue the IRP to the
> current thread). ZwCreateFile() will allocate an IRP and will
also queue it
> to the thread’s list (at the head and still same thread). So no
matter what
> happens in between, other IRPs may be queued to the thread, but
those two
> will stay together. When the filter’s dispatch routine is
invoked, if the
> IRP is followed by the dummy IRP (Irp->ThreadListEntry), then it’s a
> recursive call. This assumes that the IRP that the io manager created in
> ZwCreateFile() is the one that the filter sees.

From my understanding of your idea you solve the recursion
detection problem not
the deadlock problem induced by reentering the stack ?

>
>
> The ‘shadow device’ solution is fine too. It has the side effect that
> filters that attached to the original device, won’t see those
> ZwCreateFile()-s. On the other hand, filters may notice the
‘shadow device’,
> attach to them, and get confused.

In my implementation the shadow device is not attach to any other
filter device
(it is almost a perfect duplicate of the original device object) It use a
private interface in the driver with the original DO and talk
directly to what
it thinks is the bottom of the driver stack. They are some
catches with this
approach though. (ex: closehandle() is dangerous in this case,
for example as
you may re-enter the top of the stack because the iomanager will
still use the
original vpb to find the top of the stack, if I recall).

>
> Sara
>
> -----Original Message-----
> From: Tony Mason
> > To: File Systems Developers
> > Date: Thursday, July 13, 2000 8:04 AM
> > Subject: [ntfsd] RE: preventing recursive loop in create
> dispatch hand ler
> >
> >
>
> …
>
> >
>
> Jerome.
>
>
> —
> You are currently subscribed to ntfsd as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to $subst(‘Email.Unsub’)
>