Matching up IRP_MJ_WRITEs with their _OPENs

I’m working on a file systems filter driver that watches create/open requests and verifies the opening files against a user-mode application (using shared events and memory), which in turn responds back as to whether or not it wants to receive the write events for the given file. The driver keeps an internal table of all opened files that the user-mode app wants and as write events come in, it checks the file name against this table to know whether to signal user-mode with the write event. Currently this checking is using the file names that were saved from the file object during the open event (and added to the table) and comparing them against the write event’s file name. My question is, is there something else I could use besides the file name to indicate to me that a Write event goes with a particular Open event? I’ve tried using the File Object’s kernel virtual address but this value changes between the open and write events in some cases. Do I need to ObReferenceObject on the file object to ensure its memory address won’t change? Any help is appreciated.

Regards,

Mike Wick
Developer; Software Pursuits

If you are saying that you acccess the filename during the IRP_MJ_WRITE
handler, then you need to read the FAQ at OSR. You can’t do this.

The addresses of fileobjects don’t change. You are seeing, possibly, a
stream file object which is created by NTFS to perform flushing of the
open file.

If you want to track per file open instances, then the fileobject
address is a good way to track along with the FsContext indicator to
ensure you don’t miss the stream FO’s mentioned above.

Again, read the FAQ about these issues at the OSR site.

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: Tuesday, April 01, 2003 5:28 PM
To: File Systems Developers
Subject: [ntfsd] Matching up IRP_MJ_WRITEs with their _OPENs

I’m working on a file systems filter driver that watches create/open
requests and verifies the opening files against a user-mode application
(using shared events and memory), which in turn responds back as to
whether or not it wants to receive the write events for the given file.
The driver keeps an internal table of all opened files that the
user-mode app wants and as write events come in, it checks the file name
against this table to know whether to signal user-mode with the write
event. Currently this checking is using the file names that were saved
from the file object during the open event (and added to the table) and
comparing them against the write event’s file name. My question is, is
there something else I could use besides the file name to indicate to me
that a Write event goes with a particular Open event? I’ve tried using
the File Object’s kernel virtual address but this value changes between
the open and write events in some cases. Do I need to ObReferenceObject
on the file object to ensure its memory address won’t change? Any help
is appreciated.

Regards,

Mike Wick
Developer; Software Pursuits


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

Mike:
Direct answer to your Q would be that it’s better using FileObject as a key
in your table (not file name). File name is not a good option because in the
write dispatch you can’t use FileName field of the coming FileObject
(generally, you can trust this field only in the way down in create
dispatch). So, you have to roll your own QueryInformation IRP to get file
name for this FileObject which will certainly kill the performance. If you
don’t distinguish between different handles of a file and only care about
file on disk then you can use FileObject->FsContext field as the index
(again, after driver below you successfully completed create IRP). This
filed uniquely identifies file (stream) on disk. What you see as “different”
FileObjects are (most likely) internal streams that FS below you creates and
(thus) you don’t see create dispatches for them. But they share same
FsContext as the file you saw in create dispatch. The biggest problem with
FsContext approach is defining when it’s gone. Solution to this problem is
described in NTInsider article that (I believe) is available at OSR’s web
site.

Regards,

Vladimir

-----Original Message-----
From: Mike Wick [mailto:xxxxx@spursuits.com]
Sent: Tuesday, April 01, 2003 4:28 PM
To: File Systems Developers
Subject: [ntfsd] Matching up IRP_MJ_WRITEs with their _OPENs

I’m working on a file systems filter driver that watches create/open
requests and verifies the opening files against a user-mode application
(using shared events and memory), which in turn responds back as to whether
or not it wants to receive the write events for the given file. The driver
keeps an internal table of all opened files that the user-mode app wants and
as write events come in, it checks the file name against this table to know
whether to signal user-mode with the write event. Currently this checking
is using the file names that were saved from the file object during the open
event (and added to the table) and comparing them against the write event’s
file name. My question is, is there something else I could use besides the
file name to indicate to me that a Write event goes with a particular Open
event? I’ve tried using the File Object’s kernel virtual address but this
value changes between the open and write events in some cases. Do I need to
ObReferenceObject on the file object to ensure its memory address won’t
change? Any help is appreciated.

Regards,

Mike Wick
Developer; Software Pursuits


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

I am probably going to forget something important here, but here goes:

  1. Read the OSR IFS FAQ.
  2. Look at the filter drivers in the XP SP1 IFS Kit. Check both the W2K &
    XP versions of those driver to see how they determine context. It is
    different on W2K & XP, but you can use the W2K method on XP, though I would
    recommend against it.
  3. You do know that file names are only valid during the CREATE dispatch
    processing? And that there are several different ways of specifying the
    file name (SFN, LFN, relative path, etc.)?
  4. There is information in the CREATE that has information about the file
    being available for writing to limit the number of files being tracked.
  5. Look at FsContext, though that can be used, but I have seen the same
    file opened with different FsContext values.

----- Original Message -----
From: “Mike Wick”
To: “File Systems Developers”
Sent: Tuesday, April 01, 2003 7:27 PM
Subject: [ntfsd] Matching up IRP_MJ_WRITEs with their _OPENs

I’m working on a file systems filter driver that watches create/open
requests and verifies the opening files against a user-mode application
(using shared events and memory), which in turn responds back as to whether
or not it wants to receive the write events for the given file. The driver
keeps an internal table of all opened files that the user-mode app wants and
as write events come in, it checks the file name against this table to know
whether to signal user-mode with the write event. Currently this checking
is using the file names that were saved from the file object during the open
event (and added to the table) and comparing them against the write event’s
file name. My question is, is there something else I could use besides the
file name to indicate to me that a Write event goes with a particular Open
event? I’ve tried using the File Object’s kernel virtual address but this
value changes between the open and write events in some cases. Do I need to
ObReferenceObject on the file object to ensure its memory address won’t
change? Any help is appreciated.

Regards,

Mike Wick
Developer; Software Pursuits


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