User-level close tracking

NTFSD
1

I am working on a filter driver to facilitate locking between two related files.  So when fileA is opened for write, an attempt to open related fileB is denied access until fileA is closed.

 

My problem is knowing when I can release the lock for fileA.  From what I understand IRP_MJ_CLEANUP requests are performed when all user-mode handles are closed, so I thought that was the answer.  But what I’m seeing when I manipulate an mdb file doesn’t support this.  This is what I’m seeing:

 

  • Open mdb file in Access:
     + IRP_MJ_CREATE
     + IRP_MJ_CLEANUP

 

  • Add a table:
     + IRP_MJ_WRITEs

 

  • Close mdb file:
     + IRP_MJ_WRITEs

 

I expected to see another IRP_MJ_CREATE for write access when I added a table, since IRP_MJ_CLEANUP happened after I opened the file, and I expected to see an IRP_MJ_CLEANUP at some point when I closed the file or sometime after the writes since I must have had an open handle when I was performing the writes.  I’m not seeing either of these things.  Please note I’m only tracking activity when a CREATE request comes in with write access.  Is this where I’m going wrong?  Maybe there’s a better way for me to do my locking scheme?  Thanks in advance for any help or guidance.

 

-Mike

2

This seems like reasonable (and expected) behavior if the file is memory
mapped. You don’t mention if that IRP_MJ_WRITE is a paging I/O or not,
but my guess is that it in fact IS a paging I/O operation. Thus, the
I/O operations are done via the paging interface - and the file need not
be opened by the application to perform this operation.

Regards,

Tony

Tony Mason

Consulting Partner

OSR Open Systems Resources, Inc.

http://www.osr.com http:</http:>

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mike Wick
Sent: Thursday, November 18, 2004 6:20 PM
To: ntfsd redirect
Subject: [ntfsd] User-level close tracking

I am working on a filter driver to facilitate locking between two
related files. So when fileA is opened for write, an attempt to open
related fileB is denied access until fileA is closed.

My problem is knowing when I can release the lock for fileA. From what
I understand IRP_MJ_CLEANUP requests are performed when all user-mode
handles are closed, so I thought that was the answer. But what I’m
seeing when I manipulate an mdb file doesn’t support this. This is what
I’m seeing:

  • Open mdb file in Access:
  • IRP_MJ_CREATE
  • IRP_MJ_CLEANUP
  • Add a table:
  • IRP_MJ_WRITEs
  • Close mdb file:
  • IRP_MJ_WRITEs

I expected to see another IRP_MJ_CREATE for write access when I added a
table, since IRP_MJ_CLEANUP happened after I opened the file, and I
expected to see an IRP_MJ_CLEANUP at some point when I closed the file
or sometime after the writes since I must have had an open handle when I
was performing the writes. I’m not seeing either of these things.
Please note I’m only tracking activity when a CREATE request comes in
with write access. Is this where I’m going wrong? Maybe there’s a
better way for me to do my locking scheme? Thanks in advance for any
help or guidance.

-Mike

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

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

3

This means that Jet uses memory-mapped files (and probably FlushViewOfFile) to work with MDBs.

The sequence of
hFile = CreateFile();
hSection = CreateFileMapping(hFile);
CloseHandle(hFile);
MapViewOfFile(hSection);
CloseHandle(hSection);
// here write to the mapped data
FlushViewOfFile()

  • will generate exactly the traffic you see.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

----- Original Message -----
From: Mike Wick
To: Windows File Systems Devs Interest List
Sent: Friday, November 19, 2004 2:19 AM
Subject: [ntfsd] User-level close tracking

I am working on a filter driver to facilitate locking between two related files. So when fileA is opened for write, an attempt to open related fileB is denied access until fileA is closed.

My problem is knowing when I can release the lock for fileA. From what I understand IRP_MJ_CLEANUP requests are performed when all user-mode handles are closed, so I thought that was the answer. But what I’m seeing when I manipulate an mdb file doesn’t support this. This is what I’m seeing:

  • Open mdb file in Access:
  • IRP_MJ_CREATE
  • IRP_MJ_CLEANUP
  • Add a table:
  • IRP_MJ_WRITEs
  • Close mdb file:
  • IRP_MJ_WRITEs

I expected to see another IRP_MJ_CREATE for write access when I added a table, since IRP_MJ_CLEANUP happened after I opened the file, and I expected to see an IRP_MJ_CLEANUP at some point when I closed the file or sometime after the writes since I must have had an open handle when I was performing the writes. I’m not seeing either of these things. Please note I’m only tracking activity when a CREATE request comes in with write access. Is this where I’m going wrong? Maybe there’s a better way for me to do my locking scheme? Thanks in advance for any help or guidance.

-Mike

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

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

4

Hi Tony,

Thanks for the reply.  Sorry, I should have mentioned that the IRP_MJ_WRITEs are not paging I/O requests.  My filter ignores paging I/O writes, as it is my understanding that these requests are made by the Cache Manager to the backing store, and that it works out to be extraneous noise since the original non-paging request would have already been processed.  Am I wrong here?  It seems like I’m getting all the blocks I need to correctly replicate by ignoring paging I/O but maybe there’s a scenario that blows this assumption out of the water?  That’s a separate question I realize.

Back to the original question.  :)  When I make a change to a text file in Notepad, which I believe does memory-mapping, I get the expected sequence of events:

  • Change #1:
  • IRP_MJ_CREATE
  • IRP_MJ_WRITE
  • IRP_MJ_SET_INFORMATION
  • IRP_MJ_CLEANUP

+Change #2:

  • IRP_MJ_CREATE
  • IRP_MJ_WRITE
  • IRP_MJ_SET_INFORMATION
  • IRP_MJ_CLEANUP

I see what I expected to see in Access: a second CREATE request after the first CLEANUP and another CLEANUP request after the second change.  Maybe my whole approach is wrong?  I really just want a way to know that Access or any app is done with the file so I can safely release the lock.

-Mike

From: xxxxx@lists.osr.com

[mailto:xxxxx@lists.osr.com] On Behalf Of Tony Mason

Sent: Thursday, November 18, 2004 3:47 PM

To: Windows File Systems Devs Interest List

Subject: RE: [ntfsd] User-level close tracking

This seems like reasonable (and expected) behavior if the file is memory

mapped.  You don’t mention if that IRP_MJ_WRITE is a paging I/O or not,

but my guess is that it in fact IS a paging I/O operation.  Thus, the

I/O operations are done via the paging interface - and the file need not

be opened by the application to perform this operation.

Regards,

Tony

Tony Mason

Consulting Partner

OSR Open Systems Resources, Inc.

http://www.osr.com http:</http:>

From: xxxxx@lists.osr.com

[mailto:xxxxx@lists.osr.com] On Behalf Of Mike Wick

Sent: Thursday, November 18, 2004 6:20 PM

To: ntfsd redirect

Subject: [ntfsd] User-level close tracking

I am working on a filter driver to facilitate locking between two

related files.  So when fileA is opened for write, an attempt to open

related fileB is denied access until fileA is closed.

My problem is knowing when I can release the lock for fileA.  From what

I understand IRP_MJ_CLEANUP requests are performed when all user-mode

handles are closed, so I thought that was the answer.  But what I’m

seeing when I manipulate an mdb file doesn’t support this.  This is what

I’m seeing:

  • Open mdb file in Access:

  + IRP_MJ_CREATE

  + IRP_MJ_CLEANUP

  • Add a table:

  + IRP_MJ_WRITEs

  • Close mdb file:

  + IRP_MJ_WRITEs

I expected to see another IRP_MJ_CREATE for write access when I added a

table, since IRP_MJ_CLEANUP happened after I opened the file, and I

expected to see an IRP_MJ_CLEANUP at some point when I closed the file

or sometime after the writes since I must have had an open handle when I

was performing the writes.  I’m not seeing either of these things.

Please note I’m only tracking activity when a CREATE request comes in

with write access.  Is this where I’m going wrong?  Maybe there’s a

better way for me to do my locking scheme?  Thanks in advance for any

help or guidance.

-Mike

Questions? First check the IFS FAQ at

https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@osr.com

To unsubscribe send a blank email to xxxxx@lists.osr.com

Questions? First check the IFS FAQ at

https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: unknown lmsubst tag argument:

‘’

To unsubscribe send a blank email to xxxxx@lists.osr.com

5

>I/O requests. My filter ignores paging I/O writes,

It would be a much better idea to only monitor the noncached writes, be them
paging or nonpaging.

This means that you’re filtering between the disk surface and the cache (or
between the disk surface and the app which uses memory-mapped files, or between
the disk surface and the app which uses noncached file opens) - and nothing can
be skipped.

Filtering between the cache and the app is useless.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

6

Hi Maxim,<?xml:namespace prefix = o ns = “urn:schemas-microsoft-com:office:office” /><o:p></o:p>

<o:p> </o:p>

Thank you for the reply.  Ah, I see.  So when I open the MDB, the CreateFile() up to the CloseHandle() happen, and when I start making changes (like adding a table or closing the file) the FlushViews() occur.  Do I have that right?  That would certainly explain what I’m seeing, and it makes what I’m trying to do pretty tricky if not impossible.  I guess it’s back to the drawing board…

<o:p> </o:p>

-Mike<o:p></o:p>

From: “Mike Wick”

>To:
>Subject: FW: [ntfsd] User-level close tracking
>Date: Fri, 19 Nov 2004 10:47:10 -0800
>
>
>
>
>
> ________________________________
>
>From: xxxxx@lists.osr.com
>[mailto:xxxxx@lists.osr.com] On Behalf Of Maxim S.
>Shatskih
>Sent: Friday, November 19, 2004 10:01 AM
>To: Windows File Systems Devs Interest List
>Subject: Re: [ntfsd] User-level close tracking
>
>
>
> This means that Jet uses memory-mapped files (and probably
>FlushViewOfFile) to work with MDBs.
>
>
>
> The sequence of
>
> hFile = CreateFile();
>
> hSection = CreateFileMapping(hFile);
>
> CloseHandle(hFile);
>
> MapViewOfFile(hSection);
>
> CloseHandle(hSection);
>
> // here write to the mapped data
>
> FlushViewOfFile()
>
>
>
> - will generate exactly the traffic you see.
>
>
>
>Maxim Shatskih, Windows DDK MVP
>StorageCraft Corporation
>xxxxx@storagecraft.com
>http://www.storagecraft.com
>
>
>
> ----- Original Message -----
>
> From: Mike Wick mailto:xxxxx
>
> To: Windows File Systems Devs Interest List
>mailto:xxxxx
>
> Sent: Friday, November 19, 2004 2:19 AM
>
> Subject: [ntfsd] User-level close tracking
>
>
>
> I am working on a filter driver to facilitate locking between
>two related files. So when fileA is opened for write, an attempt to
>open related fileB is denied access until fileA is closed.
>
>
>
> My problem is knowing when I can release the lock for fileA.
>From what I understand IRP_MJ_CLEANUP requests are performed when all
>user-mode handles are closed, so I thought that was the answer. But
>what I’m seeing when I manipulate an mdb file doesn’t support this.
>This is what I’m seeing:
>
>
>
> - Open mdb file in Access:
> + IRP_MJ_CREATE
> + IRP_MJ_CLEANUP
>
>
>
> - Add a table:
> + IRP_MJ_WRITEs
>
>
>
> - Close mdb file:
> + IRP_MJ_WRITEs
>
>
>
> I expected to see another IRP_MJ_CREATE for write access when I
>added a table, since IRP_MJ_CLEANUP happened after I opened the file,
>and I expected to see an IRP_MJ_CLEANUP at some point when I closed the
>file or sometime after the writes since I must have had an open handle
>when I was performing the writes. I’m not seeing either of these
>things. Please note I’m only tracking activity when a CREATE request
>comes in with write access. Is this where I’m going wrong? Maybe
>there’s a better way for me to do my locking scheme? Thanks in advance
>for any help or guidance.
>
>
>
> -Mike
>
> —
> Questions? First check the IFS FAQ at
>https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@storagecraft.com
>
> To unsubscribe send a blank email to
>xxxxx@lists.osr.com
>
>—
>Questions? First check the IFS FAQ at
>https://www.osronline.com/article.cfm?id=17
>
>You are currently subscribed to ntfsd as: unknown lmsubst tag argument:
>‘’
>To unsubscribe send a blank email to xxxxx@lists.osr.com
>
</mailto:xxxxx></mailto:xxxxx>