ah yes…
Thank you very much (you too Paul).
-Joel
-----Original Message-----
From: Jamey Kirby [mailto:xxxxx@storagecraft.com]
Sent: Wednesday, July 19, 2000 2:05 PM
To: File Systems Developers
Subject: [ntfsd] RE: preventing recursive loop in create dispatch hand ler
See my code sample I posted. You need to sync the call via the completion
routine so that when you resen the IRP, you are again back in the original
process/thread context.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Smith, Joel
Sent: Wednesday, July 19, 2000 10:49 AM
To: File Systems Developers
Subject: [ntfsd] RE: preventing recursive loop in create dispatch hand ler
Jamey,
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@storagecraft.com
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@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>