RE: IFS Kit samples questions [2]

NTFSD
1

In our filter drivers that need to handle the mount request, we
synchronize it. We initialize an event object and pass it to a
completion handler. On completion, we set the event and return
STATUS_MORE_PROCESSING_REQUIRED. In the mount code, we wait on the
completion event. The mount operation is synchronous by nature and so
far we have experienced no problems under some very harsh conditions.
This code works on NT 3.51, NT 4.0, Windows 2000 and Windows XP.

Since the IO manager can do nothing but wait for the mount to complete,
it has no detrimental effect if wait in the driver mount path.

Jamey Kirby
StorageCraft, inc.
xxxxx@storagecraft.com
www.storagecraft.com

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Fuller, Rob
Sent: Monday, May 13, 2002 8:34 AM
To: File Systems Developers
Subject: [ntfsd] RE: IFS Kit samples questions [2]

I don’t know if you’ve tried syncing back with dispatch on a mount
request, but certain versions of NT will deadlock in this scenario.
Thus, I don’t recommend trying to save the RealDevice in a local
variable.

-----Original Message-----
From: Molly Brown [mailto:xxxxx@windows.microsoft.com]
Sent: Monday, May 13, 2002 10:25 AM
To: File Systems Developers
Subject: [ntfsd] RE: IFS Kit samples questions [2] (passing RealDevice
to completion)

Leonid,

I don’t have the TFILTER sample readily available, but the reason we
threw it out and started over with the FileSpy sample in the W2K version
of the IFS Kit was because it had a lot of problems. Therefore, I’m
willing to agree that anything that looks like a bug is probably a bug
:).

As far as the manipulations of the DeviceObject parameter during mount
processing, the only reason the DeviceObject parameter is change is to
remember the pointer to the real device is because we need it to process
the mount request after it has been successfully completed by the file
system. If you were passing some context to the completion routine, you
could store the real device there, or if you were synchronizing back to
the dispatch routine once the mount operation was completed by the file
system, you could save the real device in a local variable.

The real device, which represents the storage stack, needs to be saved
because there are cases where the VPB will be changed by the file system
during the mount processing (FAT is known to do this sometimes). When
the VPB is changed, this change will be reflected in the real device’s
VBP. Once the file system has succeeded the mount, we can find the
appropriate file system stack by going through the real device’s VPB to
get file system’s volume device object.

One final thing – I’d like to give a plug for getting a more recent
version of the IFS Kit. We haven’t shipped the TFILTER sample since the
NT 4.0 kit and SFILTER has been much improved since then as well. This
area of mount processing is one that we particularly revamped in the
Windows XP versions of the samples by added a lot more comments and
removing some of the confusing logic. The majority of this code is not
Windows XP specific, so it should be helpful even if your driver is for
NT 4.0 or W2K clients.

Thanks,
Molly Brown
Microsoft Corporation

This posting is provided “AS IS” with no warranties, and confers no
rights.

-----Original Message-----
From: Leonid Zhigunov [mailto:xxxxx@progate.spb.ru]
Sent: Monday, May 13, 2002 2:30 AM
To: File Systems Developers
Subject: [ntfsd] IFS Kit samples questions [2]

Hi,

Could anybody explain me some issues in filter samples.
I will be very much appreciated for your help.

In SFILTER and TFILTER the following code is used while processing
IRP_MJ_MOUNT_VOLUME request:

In dispatch routine before calling IoCallDriver() the current stack is
changed in SFILTER:
irpSp->Parameters.MountVolume.DeviceObject =
irpSp->Parameters.MountVolume.Vpb->RealDevice;

but the next stack is changed in TFILTER:
nextStack->Parameters.MountVolume.DeviceObject =
currentStack->Parameters.MountVolume.Vpb->RealDevice ;

  1. As I understand, this is a bug in TFILTER sample, because both of
    them
    use
    the current stck in their completion routines to get vpb->DeviceObject:
    vpb = irpSp->Parameters.MountVolume.DeviceObject->Vpb;
    Am I right?

  2. Why they replace DeviceObject parameter? Just to remember pointer to
    RealDevice,
    cause old VPB structure can be deleted after IoCallDriver()?

  3. Why the completion routine returns STATUS_MORE_PROCESSING_REQUIRED
    in TFILTER sample?

Thanks in advance,
Leonid.

You are currently subscribed to ntfsd as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to %%email.unsub%%

You are currently subscribed to ntfsd as: xxxxx@inin.com
To unsubscribe send a blank email to %%email.unsub%%

You are currently subscribed to ntfsd as: xxxxx@storagecraft.com
To unsubscribe send a blank email to %%email.unsub%%