Virtual (pseudo) FS question

NTFSD
1

Hello,

I have a general question for any FS/FS filter experts out there. I’m doing
a “virtual file system” driver, whereby I actually create FileObjects and
control their virtual memory state while running on top of FAT, for example.
I also have my own idea of a file control block. Because I’m in charge of
controlling the VM state for my own FileObjects, I must implement such
callback routines as:

AcquireFileForNtCreateSection
ReleaseFileForNtCreateSection
AcquireForModWrite
ReleaseForModWrite
AcquireForCcFlush
ReleaseForCcFlush

My question is how do I (or is it even possible) have the callback be
directed at my device object’s fast i/o dispatch instead of FAT’s device
object. I ask this because upon looking at FsRtlAcquireFileExclusiveCommon,
it seems that this routine calls IoGetBaseFileSystemDeviceObject to get the
device object whose fastiodispatch it decides to use. Upon analysis
IoGetBaseFileSystemDeviceObject looks like it returns the device object
field from the file object (what I want) ONLY if the VPB fields
fileobject->DeviceObject->VPB and fileobject->VPB are NULL. I obviously can
force these to be NULL.

Would I have to use the filter callbacks methods to hook these calls, or is
the only solution to actually directly hook them? I believe I could simply
use IoCreateStreamFileObjectLite( NULL, myDeviceObject ) to create my own
file object that points to my device object, but then how can I substitute
this for the FO that a create IRP gives me, which contains an FO that has
fileObject->DeviceObject pointing at the realdevice for the VPB?

Thanks for any help,
Matt

2

(I fixed formatting)
Hello,

I have a general question for any FS/FS filter experts out there. I’m doing
a “virtual file system” driver, whereby I actually create FileObjects and
control their virtual memory state while running on top of FAT, for example.
I also have my own idea of a file control block. Because I’m in charge of
controlling the VM state for my own FileObjects, I must implement such
callback routines as:

AcquireFileForNtCreateSection
ReleaseFileForNtCreateSection
AcquireForModWrite
ReleaseForModWrite
AcquireForCcFlush
ReleaseForCcFlush

My question is how do I (or is it even possible) have the callback be
directed at my device object’s fast i/o dispatch instead of FAT’s device
object. I ask this because upon looking at FsRtlAcquireFileExclusiveCommon,
it seems that this routine calls IoGetBaseFileSystemDeviceObject to get the
device object whose fastiodispatch it decides to use. Upon analysis
IoGetBaseFileSystemDeviceObject looks like it returns the device object
field from the file object (what I want) ONLY if the VPB fields
fileobject->DeviceObject->VPB and fileobject->VPB are NULL. I obviously
cannot force these to be NULL.

Would I have to use the filter callbacks methods to hook these calls, or is
the only solution to actually directly hook them? I believe I could simply
use IoCreateStreamFileObjectLite( NULL, myDeviceObject ) to create my own
file object that points to my device object, but then how can I substitute
this for the FO that a create IRP gives me, which contains an FO that has
fileObject->DeviceObject pointing at the realdevice for the VPB?

Thanks for any help,
Matt

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Matthew N. White
Sent: Saturday, April 23, 2005 12:03 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] Virtual (pseudo) FS question

Hello,

I have a general question for any FS/FS filter experts out there. I’m doing
a “virtual file system” driver, whereby I actually create FileObjects and
control their virtual memory state while running on top of FAT, for example.
I also have my own idea of a file control block. Because I’m in charge of
controlling the VM state for my own FileObjects, I must implement such
callback routines as:

AcquireFileForNtCreateSection
ReleaseFileForNtCreateSection
AcquireForModWrite
ReleaseForModWrite
AcquireForCcFlush
ReleaseForCcFlush

My question is how do I (or is it even possible) have the callback be
directed at my device object’s fast i/o dispatch instead of FAT’s device
object. I ask this because upon looking at FsRtlAcquireFileExclusiveCommon,
it seems that this routine calls IoGetBaseFileSystemDeviceObject to get the
device object whose fastiodispatch it decides to use. Upon analysis
IoGetBaseFileSystemDeviceObject looks like it returns the device object
field from the file object (what I want) ONLY if the VPB fields
fileobject->DeviceObject->VPB and fileobject->VPB are NULL. I obviously
fileobject->DeviceObject->can
force these to be NULL.

Would I have to use the filter callbacks methods to hook these calls, or is
the only solution to actually directly hook them? I believe I could simply
use IoCreateStreamFileObjectLite( NULL, myDeviceObject ) to create my own
file object that points to my device object, but then how can I substitute
this for the FO that a create IRP gives me, which contains an FO that has
fileObject->DeviceObject pointing at the realdevice for the VPB?

Thanks for any help,
Matt

Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@bitarmor.com To unsubscribe
send a blank email to xxxxx@lists.osr.com

3

On Sat, 2005-04-23 at 10:03, Matthew N. White wrote:

I have a general question for any FS/FS filter experts out there. I’m doing
a “virtual file system” driver, whereby I actually create FileObjects and
control their virtual memory state while running on top of FAT, for example.
I also have my own idea of a file control block. Because I’m in charge of
controlling the VM state for my own FileObjects, I must implement such
callback routines as:

AcquireFileForNtCreateSection
ReleaseFileForNtCreateSection
AcquireForModWrite
ReleaseForModWrite
AcquireForCcFlush
ReleaseForCcFlush

My question is how do I (or is it even possible) have the callback be
directed at my device object’s fast i/o dispatch instead of FAT’s device
object.

These callbacks are only called on the driver for the bottom device
object in a stack. On Windows XP, Server 2003, and very recent patches
of Windows 2000, you can call FsRtlRegisterFileSystemFilterCallbacks()
to register callbacks that will handle all of those cases-- it
lets you intercept calls before and after the locking on the underlying
driver. It doesn’t matter what you return in the “after” case, but
in the “before” case, returning an error will prevent the call to
the underlying driver, returning STATUS_SUCCESS will pass the call
down to the underlying driver, and returning the (as far as I can tell)
undocumented STATUS_FSFILTER_OP_COMPLETED_SUCCESSFULLY (0x126)
will cause prevent the call to the underlying driver and return
success.

If your filter has to work on older versions of Windows 2000, there
are instructions in the ntfsd archives on how to hack the underlying
driver by swapping in your own functions in the fast I/O dispatch
table.

4

On Mon, 25 Apr 2005, Max Kaehn wrote:

If your filter has to work on older versions of Windows 2000, there
are instructions in the ntfsd archives on how to hack the underlying
driver by swapping in your own functions in the fast I/O dispatch
table.

A detailed discussion on this method was posted by Ravisankar
Pudipeddi, it can be found in the archive at:
http://www.osronline.com/lists_archive/ntfsd/thread1922.html

Bo Branten