Tracking IRP_MJ_CREATEs

I’m working on an FSFD that does file locking by tracking and denying appropriate IRP_MJ_CREATE.  It works fine as long as I’m trying to open the file locally, but when I access it via a mapped drive on another machine, I don’t see it.  From watching IRP activity on both client and server using FileMon, it looks like the IRPs are created on the client, but there’s no IRP equivalent on the server.  Somehow the server has to be performing file I/O on the client’s behalf, right?  Or is the client-side redirector completely circumventing the server’s FSD?  Thanks for any insight.

 

-Mike

Mike

I can assure you that inr our FSFD work we do see IRP_MJ_CREATE at the server side; except of course where the FastIoQueryOpen path is used see http://www.osronline.com/article.cfm?id=166 for description. I assume you attached to the relevant file system device stack on the server side?

Regards
Lyndon
“Mike Wick” wrote in message news:xxxxx@ntfsd…
I’m working on an FSFD that does file locking by tracking and denying appropriate IRP_MJ_CREATE. It works fine as long as I’m trying to open the file locally, but when I access it via a mapped drive on another machine, I don’t see it. From watching IRP activity on both client and server using FileMon, it looks like the IRPs are created on the client, but there’s no IRP equivalent on the server. Somehow the server has to be performing file I/O on the client’s behalf, right? Or is the client-side redirector completely circumventing the server’s FSD? Thanks for any insight.

-Mike

Hi Lyndon,

 

Thanks for your response.  You mentioned *relevant* device stack, and I believe that’s where I’m going wrong.  I’m only attaching to "\DosDevices".  I think I also need to attach to the Lanman Server so I can get the network requests.  Is that right?  And if so, would you happen to know the correct syntax for refering to this device when attempting to attach to it?  Thanks.

 

-Mike

 

 


OP:

I’m working on an FSFD that does file locking by tracking and denying appropriate IRP_MJ_CREATE. It works fine as long as I’m trying to open the file locally, but when I access it via a mapped drive on another machine, I don’t see it. From watching IRP activity on both client and server using FileMon, it looks like the IRPs are created on the client, but there’s no IRP equivalent on the server. Somehow the server has to be performing file I/O on the client’s behalf, right? Or is the client-side redirector completely circumventing the server’s FSD? Thanks for any insight.

Mike

Well, \DosDevices?:\ sort of thing is possible, and I dont need to attach
to lanman server - but shall I say the RightThing™, you could have a look
at Filespy from IFS KIT? Umm, what is you test client doing?

Cheers
Lyndon
“Mike Wick” wrote in message news:xxxxx@ntfsd…
Hi Lyndon,

Thanks for your response. You mentioned relevant device stack, and I
believe that’s where I’m going wrong. I’m only attaching to "\DosDevices".
I think I also need to attach to the Lanman Server so I can get the network
requests. Is that right? And if so, would you happen to know the correct
syntax for refering to this device when attempting to attach to it? Thanks.

-Mike

-------------------
OP:
I’m working on an FSFD that does file locking by tracking and denying
appropriate IRP_MJ_CREATE. It works fine as long as I’m trying to open the
file locally, but when I access it via a mapped drive on another machine, I
don’t see it. From watching IRP activity on both client and server using
FileMon, it looks like the IRPs are created on the client, but there’s no
IRP equivalent on the server. Somehow the server has to be performing file
I/O on the client’s behalf, right? Or is the client-side redirector
completely circumventing the server’s FSD? Thanks for any insight.

Hi Lyndon,

Thanks for your help.  I figured out what the problem was.  My filter was seeing the I/O, but I was ignoring the RelatedFileObject in the Create handler, which I need to use to build a complete file name.  Oops… :slight_smile:

-Mike

From: “Mike Wick”

>To:
>Subject: FW: [ntfsd] Tracking IRP_MJ_CREATEs
>Date: Wed, 16 Feb 2005 08:29:23 -0800
>
>
>
>-----Original Message-----
>From: xxxxx@lists.osr.com
>[mailto:xxxxx@lists.osr.com] On Behalf Of Lyndon J Clarke
>Sent: Tuesday, February 15, 2005 4:56 PM
>To: Windows File Systems Devs Interest List
>Subject: Re:[ntfsd] Tracking IRP_MJ_CREATEs
>
>Mike
>
>Well, \DosDevices?:\ sort of thing is possible, and I dont need to
>attach
>to lanman server - but shall I say the RightThing™, you could have a
>look
>at Filespy from IFS KIT? Umm, what is you test client doing?
>
>Cheers
>Lyndon
>“Mike Wick” wrote in message news:xxxxx@ntfsd…
>Hi Lyndon,
>
>Thanks for your response. You mentioned relevant device stack, and I
>believe that’s where I’m going wrong. I’m only attaching to
>"\DosDevices".
>I think I also need to attach to the Lanman Server so I can get the
>network
>requests. Is that right? And if so, would you happen to know the
>correct
>syntax for refering to this device when attempting to attach to it?
>Thanks.
>
>-Mike
>
>
>-------------------
>OP:
>I’m working on an FSFD that does file locking by tracking and denying
>appropriate IRP_MJ_CREATE. It works fine as long as I’m trying to open
>the
>file locally, but when I access it via a mapped drive on another
>machine, I
>don’t see it. From watching IRP activity on both client and server
>using
>FileMon, it looks like the IRPs are created on the client, but there’s
>no
>IRP equivalent on the server. Somehow the server has to be performing
>file
>I/O on the client’s behalf, right? Or is the client-side redirector
>completely circumventing the server’s FSD? Thanks for any insight.
>
>
>
>—
>Questions? First check the IFS FAQ at
>https://www.osronline.com/article.cfm?id=17
>
>You are currently subscribed to ntfsd as: xxxxx@spursuits.com
>To unsubscribe send a blank email to xxxxx@lists.osr.com