I’m working on a file systems filter driver (and am a newbie at it) that accepts file paths and reports back when there’s activity on any of these paths. This is implemented by attaching a device object to the volume when there’s a request to add a new path (assuming there’s not already a device attached) and adding the path to an array on the device’s extension. It also saves off the drive letter in the device extension so it can build the full path string when it reports it back. Anyway as create/open requests hit this device object, the IrpStack->FileObject->FileName is checked against the attached device object’s list of paths, and if the strings match, the user-mode program is signaled. My question is, is there a better way to do determine if a file is contained in a directory other than parsing the file path? Such as maybe obtaining the fscontext for the directory and plugging that and the fscontext of the i/o file and getting a yes/no response? I realize my current implementation breaks when network paths are introduced (since all network drives point to the same device object and because the path strings for network paths take the form “;:0<server_name><share_folder>”). Also, is there a definitive way to know that an incoming Irp is for a file vs. a directory? Thanks for any help.
Regards,
Mike Wick
Developer; SPI</share_folder></server_name>
First, it is assumed you are performing the filename checks on the
dispatch side of create processing.
This said, I assume you then pass this onto the completion routine to
ensure the create actually even succeeded. Note you can’t access the
F.O. filename at this point. See the FAQ at OSR.
In short, it depends. You can sometimes track previous opens of
directories to easier determine, when a relative F.O. is given, the
possible parent. Of course this all depends on how the relative open was
performed. When it is not a relative open, then a name comparison or
hashing is the quickest way, most likely. Given the fact that you would
be avoiding re-entrancy in most cases.
Pete
Peter Scott
xxxxx@KernelDrivers.com
www.KernelDrivers.com
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mike Wick
Sent: Wednesday, April 09, 2003 5:48 PM
To: File Systems Developers
Subject: [ntfsd] Filter Driver question: file objects
I’m working on a file systems filter driver (and am a newbie at it) that
accepts file paths and reports back when there’s activity on any of
these paths. This is implemented by attaching a device object to the
volume when there’s a request to add a new path (assuming there’s not
already a device attached) and adding the path to an array on the
device’s extension. It also saves off the drive letter in the device
extension so it can build the full path string when it reports it back.
Anyway as create/open requests hit this device object, the
IrpStack->FileObject->FileName is checked against the attached device
object’s list of paths, and if the strings match, the user-mode program
is signaled. My question is, is there a better way to do determine if a
file is contained in a directory other than parsing the file path? Such
as maybe obtaining the fscontext for the directory and plugging that and
the fscontext of the i/o file and getting a yes/no response? I realize
my current implementation breaks when network paths are introduced
(since all network drives point to the same device object and because
the path strings for network paths take the form “;letter>:0<server_name><share_folder>”). Also, is there a definitive
way to know that an incoming Irp is for a file vs. a directory? Thanks
for any help.
Regards,
Mike Wick
Developer; SPI
—
You are currently subscribed to ntfsd as: xxxxx@kerneldrivers.com
To unsubscribe send a blank email to xxxxx@lists.osr.com</share_folder></server_name>