RE: [ntfsd] RE: assertion while using ‘shadow device object’ recursion
removal te chniqueSo, change the disposition before sending it down. Then,
on completion restore the disposition and resend the request a second time
with the proper disposition (after closing it ofcourse); isn’t NT great!
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Smith, Joel
Sent: Tuesday, July 18, 2000 9:40 AM
To: File Systems Developers
Subject: [ntfsd] RE: assertion while using ‘shadow device object’ recu
rsion removal te chnique
Because it is important to my filter that I know the file size change
caused by IO. If I pass the create down to the FSD, and the open results in
an overwrite or superceded, then I have lost the file size. Basically, I
just need to know the size of the file before passing it down, so I can know
the delta if an overwrite ensues.
-----Original Message-----
From: Jamey Kirby [mailto:xxxxx@storagecraft.com]
Sent: Tuesday, July 18, 2000 12:00 PM
To: File Systems Developers
Subject: [ntfsd] RE: assertion while using ‘shadow device object’ recu
rsion removal te chnique
So, why not pass the CREATE request down to the lower driver, set a
completion routine to do some I/O. If you do not want the file or have
decided after the open that you want to fail, simply deref the file object
and return without an open file.
Jamey
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Smith, Joel
Sent: Tuesday, July 18, 2000 6:25 AM
To: File Systems Developers
Subject: [ntfsd] RE: assertion while using ‘shadow device object’ recu
rsion removal te chnique
Thanks Jamey,
The second case is the one I am going for (opening the target
of a create will in the IRP_MJ_CREATE handler for that create).
-----Original Message-----
From: Jamey Kirby [mailto:xxxxx@storagecraft.com]
Sent: Monday, July 17, 2000 10:16 PM
To: File Systems Developers
Subject: [ntfsd] RE: assertion while using ‘shadow device object’
recursion removal te chnique
I am sorry. Are we talking about ZwCreating a different file or the
same
file. I was assuming that he wants to open another file in the create
path
and simply bypass it from his filter. If he needs to open his own file
prior
to passing the original request along, then you are correct in that
there
will be issues.
My impression was this:
- IRP_MJ_CREATE (“'c:'hello.c”)
- ZwCreateFile(“d:\some arbitrary path\hello.c”)
Not:
- IRP_MJ_CREATE (“'c:'hello.c”)
- ZwCreateFile(“c:\hello.c”)
If the second case was the problem, I would attack it completly
different;
i.e. no ZwCreateFile() at all.
-----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com]On Behalf Of Jerome
Christatos
> Sent: Monday, July 17, 2000 6:42 PM
> To: File Systems Developers
> Subject: [ntfsd] RE: assertion while using ‘shadow device object’
> recursion removal te chnique
>
>
> Jamey,
>
> If the request is synchronous, i’m afraid spawning a thread won’t
solve
> the recursion pb:
>
> (I’m sorry if this this has been described several times)
>
> If you have 2 filters A and B.
>
> -Filter A open file1:
> -(1) Filter A lock file1 with a private lock or whatever and so all
new
> requests to this file1 are made pending until this io is completed.
>
> A give the request to B.
>
> -Filter B needs for any reason to issue a synchronous ZwCreate for
File
> 1 and spawn a thread whatever the context.
>
> In the new thread:
> -B Zwcreates() file1
> -Filter B now reenter top of the driver stack by the io manager
> (just doing its job) with the new thread.
> => The whole pb ‘shadow technique’ try to avoid <=
>
> - and so the request reenter driver A and kick point (1) above and
the
> thread now waits for the original request to complete. If the
original
> request was made synchronous by filter B it will never come back to
(1):
> deadlock.
>
>
> –
>
> I didn’t had the kind of pbs Joel have.
>
> You need messing with the irp/Fo when handling the special case to
avoid
> the ntclosehandle pb I mentioned in a previous post. (I also
remember
> now it triggered some pbs with the fastio table because NT thinks
your
> DO is now an FS).
> Anyway that’s the kind of annoyance to account for when using this
kind
> of disgusting hacks, so I’m really interested if someone has another
> generic solution to offer.
>
> Jerome.
>
> Jamey Kirby wrote:
>
> > Here is what I would do:- Create a system thread.- Post a request
of
> > some sort to open the other file (via ZwCereateFile) to a queue
that
> > the thread is waiting on.- When in the thread, open the file- If
your
> > thread is reposnsible for the ZwCreateFile call to IRP_MJ_CREATE,
then
> > you know it is your file. You can deterimine this by checking the
> > current thread on the create call or you can use the APIs in the
ifs
> > kit to interogate the IRP for this information;
> > IoGetRequestorProcess(), etc…This has several advantages:- You
> > always know that your file creates will come from a know
kernel-mode
> > thread.- If you do not need to serialize the second file open
witht he
> > first, you can complete the original request- - If you do, you can
> > still block in the create handler until your thread processes the
> > create. Create is called at passive in the calling processes
process
> > and thread context, so it is OK to let the scheduler switch to
another
> > process and/or thread and do something at this point.Create calls
are
> > slow and expensive anyhow, so another possible option, if you are
> > concerned about user context, is to create have a work queue
manager
> > that can start and process stuff in system threads that are
associated
> > with a know process; i.e. start the thread in the callers process,
> > post the request, ZwCreate the file, signal back to the create
> > dispatcher via an even that the ZwCreate stuff is complete and
then
> > terminate the thread. I doubt the overhead of creatingh the thread
> > will impose any significant impact; especially if you do not need
to
> > sync the create calls.Jamey
> >
> > -----Original Message-----
> > From: xxxxx@lists.osr.com
> > [mailto:xxxxx@lists.osr.com]On Behalf Of Smith,
> > Joel
> > Sent: Monday, July 17, 2000 4:03 PM
> > To: File Systems Developers
> > Subject: [ntfsd] assertion while using ‘shadow device
> > object’ recursion removal te chnique
> > I’ve implemented my interpretation of the ‘shadow
> > device object’ technique that has been discussed over the
> > last couple days on this group. Basically, when creating my
> > filter device I create a second ‘shadow’ device with a
> > unique name. This shadow device is, of course, not in the
> > file system device stack.
> >
> > In my filter’s IRP_MJ_CREATE handler, if I have to
> > call ZwCreateFile, instead of initializing the file name
> > with the partition’s device object’s name prepended, I
> > prepend the name of my ‘shadow’ device: (i.e.
> > \Device\shadow_0\somefile.txt). I then call ZwCreateFile.
> >
> > Also in my filter’s IRP_MJ_CREATE handler is a
> > special case to handle creates redirected to the ‘shadow’
> > device object. (i.e.
> > ZwCreate(\Device\shadow_0\somefile.txt). If a create comes
> > in for the shadow device object the special case simply
> > forwards the create to the fsd with IoCallDriver.
> >
> > This technique works well 99% of the time.
> > Occasionally, however, I get an assertion from the FSD:
> >
> > *** Assertion failed: No correspondence btwn file and device
> > in irp((IrpSp->FileObject->Vpb == NULL) &&
> > ((IrpSp->FileObject->DeviceObject != NULL) &&
> > (IrpSp->FileObject->DeviceObject->Vpb != NULL) &&
> > (IrpSp->DeviceObject == IrpSp->FileObject->DeviceO
> >
> > bject->Vpb->DeviceObject))) || ((IrpSp->FileObject->Vpb !=
> > NULL) && (IrpSp->DeviceObject ==
> > IrpSp->FileObject->Vpb->DeviceObject)) ||
lagOn(
> > Vcb->VcbState, VCB_STATE_VOLUME_MOUNTED ))
> >
> > *** Source File: D:\nt\private\ntos\cntfs\strucsup.c, line
> > 6670
> >
> > This may not be enough to tell what I’ve done wrong,
> > but its all I’ve got now. I’ll update the thread with some
> > more information tommorrow, after I continue to debug the
> > problem (I’m just hoping the problem will be obvious to one
> > of you and you can save me time :))
> >
> > Thanks,
> > Joel
> >
>
>
> —
> You are currently subscribed to ntfsd as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to $subst(‘Email.Unsub’)
>
You are currently subscribed to ntfsd as: xxxxx@ntpsoftware.com
To unsubscribe send a blank email to $subst(‘Email.Unsub’)