Dave,
I’d assumed that either (a) it was coming in via fast I/O (and hence there
was no IRP_MJ_WRITE); or (b) it was written via a mapped file. (b) is less
likely unless he wrote a program to do it, but in either case this all
sounds like typical NT behavior to me.
Regards,
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com
-----Original Message-----
From: COX,DAVID (HP-Roseville,ex1) [mailto:david_cox2@hp.com]
Sent: Tuesday, March 28, 2000 7:32 PM
To: File Systems Developers
Subject: [ntfsd] RE: IRP_MJ_CLEANUP/CLOSE redux
Tony, why doesn’t his filter see the write into cache? Maybe it’s
occuring via fast I/O?
Dave Cox
Hewlett-Packard Co.
HPSO/SSMO (Santa Barbara)
https://ecardfile.com/id/Dave+Cox
-----Original Message-----
From: Tony Mason [mailto:xxxxx@osr.com]
Sent: Monday, March 27, 2000 9:03 PM
To: File Systems Developers
Subject: [ntfsd] RE: IRP_MJ_CLEANUP/CLOSE redux
Neil,
This looks like normal NT/Windows 2000 behavior to me. Why do you expect
the IRP_MJ_WRITE to occur before the second create? I mean, the cache
manager write’s data behind quickly, but we’re talking order seconds, not
order milliseconds (which is more akin to the time delay between the file
close - the IRP_MJ_CLEANUP and the next open.)
And, of course, since there is an open cache section referencing the file
object, we can’t close it (the reference count is non-zero.)
If you want the I/O to complete, you could either change the mode to
write-through (so data won’t sit around in the cache) or you could always
flush it out when you see the IRP_MJ_CLEANUP (a good ol’
IRP_MJ_FLUSH_BUFFERS should do the trick.)
I hope this helps.
Regards,
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com
-----Original Message-----
From: Neil Weicher [mailto:xxxxx@netlib.com]
Sent: Monday, March 27, 2000 7:18 PM
To: File Systems Developers
Subject: [ntfsd] IRP_MJ_CLEANUP/CLOSE redux
Ok, so here’s the deal. I have a file filter system driver which I am
excercising with an application that does this:
- open fileA
driver sees IRP_MJ_CREATE
- read fileA
driver sees IRP_MJ_READ
- write back to fileA
- close fileA
driver sees IRP_MJ_CLEANUP
- immediately reopen fileA
driver sees IRP_MJ_CREATE
driver sees IRP_MJ_WRITE from 1st open
It appears that the driver receives the IRP_MJ_CREATE from the second Open
*before* it receives the IRP_MJ_WRITE from the first write! In addition, it
doesn’t seem to see an IRP_MJ_CLOSE at all.
Any clues as to what is going on here? How do I get the I/O from the first
open of fileA to complete before the driver goes onto the second?
Thanks.
Neil
You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to $subst(‘Email.Unsub’)
You are currently subscribed to ntfsd as: david_cox2@hp.com
To unsubscribe send a blank email to $subst(‘Email.Unsub’)
You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to $subst(‘Email.Unsub’)