RE: [ntfsd] RE: assertion while using ‘shadow device object’ recursion
removal te chniqueSo, 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’)