wxp SP2 IoCancelFileOpen Change and problem

Ichiro_Akimoto-2 · May 31, 2005, 12:19pm

I observed that the internal protocol of IoCancelFileOpen() changed by WXP
SP2.

In older versions IoCancelFileOpen() sends IRP_MJ_CLEANUP and IRP_MJ_CLOSE.

In WXP SP2 IoCancelFileOpen() sends only IRP_MJ_CLEANUP.
If the reference count of the file object is reduced to zero
IRP_MJ_CLOSE is sent by IoManager.(I Think.)
This changes the flow of IRP_MJ_CREAT and IRP_MJ_CLOSE that a filter driver
sees.

ex.
In older versions
Create -> Filter driver —(Create)-----> Filesystem
STATUS_SUCESS <---------------
IoCancelFileOpen --(CleanUp)–>
–(Close)---->
<- STATUS_ACCESS_DENIED(Filtrer driver generates)
In WXP SP2
Create -> Filter driver —(Create)-----> Filesystem
STATUS_SUCESS <---------------
IoCancelFileOpen --(CleanUp)–>
<- STATUS_ACCESS_DENIED(Filter driver generates)
Close —> ----->

My first question is:
Is this change a well-known fact? Is this a fix of something or new
feature?

I also observed the case Creates and Closes don’t balance in WXP SP2.
If a filter driver fails Create after sending down it and cancel it
by IoCancelFileOpen() in case of file deletion.

ex.
(explorer SHIFT+DEL)
Create -> Filter driver --(Create)------> Filesystem
STATUS_SUCCESS <--------------
IoCancelFileOpen --(CleanUp)–>
<- STATUS_ACCESS_DENIED
Close -> Filter Driver --(Close)------->
<- STATUS_SUCCESS ----------------
Create -> Filter driver --(Create)------> Filesystem
(Retry) STATUS_SUCCESS <--------------
IoCancelFileOpen --(CleanUp)–>
<- STATUS_ACCESS_DENIED
Close -> Filter Driver --(Close)------->
<- STATUS_SUCCESS ----------------
Create -> Filter driver --(Create)------> Filesystem
(Retry) STATUS_SUCCESS <--------------
IoCancelFileOpen --(CleanUp)–>
<- STATUS_ACCESS_DENIED

An external symptom of this is:
If the target of Create is a file in the removable media
you can’t safely remove the device because of the lost Close.
But you can open the file after it because CleanUp has been finished.

My second question is:
Is this a bug of IoManager or something known?
Does someone have the same experience?
If it is a bug one obvious workaround of this is to replace
IoCancelFileOpen()
by sending CleanUp and Close by myself as if old versions.
But I wonder if there is a better solution.

Ichiro Akimoto

OSR_Community_User · May 31, 2005, 12:48pm

See http://www.osronline.com/article.cfm?id=219. There are valid
reasons for not sending the IRP_MJ_CLOSE down; your mistake is in
assuming no other filter has used the file object in the interim, which
is not guaranteed to be correct.

I recently had to assist in debugging such a situation - you can read
about it http://www.osronline.com/article.cfm?article=379. This is an
explanation of why the solution you described doesn’t work properly, and
why IoCancelFileOpen was changed.

Regards,

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ichiro Akimoto
Sent: Tuesday, May 31, 2005 12:19 PM
To: ntfsd redirect
Subject: [ntfsd] wxp SP2 IoCancelFileOpen Change and problem

I observed that the internal protocol of IoCancelFileOpen() changed by
WXP
SP2.

In older versions IoCancelFileOpen() sends IRP_MJ_CLEANUP and
IRP_MJ_CLOSE.

In WXP SP2 IoCancelFileOpen() sends only IRP_MJ_CLEANUP.
If the reference count of the file object is reduced to zero
IRP_MJ_CLOSE is sent by IoManager.(I Think.)
This changes the flow of IRP_MJ_CREAT and IRP_MJ_CLOSE that a filter
driver
sees.

ex.
In older versions
Create -> Filter driver —(Create)-----> Filesystem
STATUS_SUCESS <---------------
IoCancelFileOpen --(CleanUp)–>
–(Close)---->
<- STATUS_ACCESS_DENIED(Filtrer driver generates)
In WXP SP2
Create -> Filter driver —(Create)-----> Filesystem
STATUS_SUCESS <---------------
IoCancelFileOpen --(CleanUp)–>
<- STATUS_ACCESS_DENIED(Filter driver generates)
Close —> ----->

My first question is:
Is this change a well-known fact? Is this a fix of something or new
feature?

I also observed the case Creates and Closes don’t balance in WXP SP2.
If a filter driver fails Create after sending down it and cancel it
by IoCancelFileOpen() in case of file deletion.

ex.
(explorer SHIFT+DEL)
Create -> Filter driver --(Create)------> Filesystem
STATUS_SUCCESS <--------------
IoCancelFileOpen --(CleanUp)–>
<- STATUS_ACCESS_DENIED
Close -> Filter Driver --(Close)------->
<- STATUS_SUCCESS ----------------
Create -> Filter driver --(Create)------> Filesystem
(Retry) STATUS_SUCCESS <--------------
IoCancelFileOpen --(CleanUp)–>
<- STATUS_ACCESS_DENIED
Close -> Filter Driver --(Close)------->
<- STATUS_SUCCESS ----------------
Create -> Filter driver --(Create)------> Filesystem
(Retry) STATUS_SUCCESS <--------------
IoCancelFileOpen --(CleanUp)–>
<- STATUS_ACCESS_DENIED

An external symptom of this is:
If the target of Create is a file in the removable media
you can’t safely remove the device because of the lost Close.
But you can open the file after it because CleanUp has been finished.

My second question is:
Is this a bug of IoManager or something known?
Does someone have the same experience?
If it is a bug one obvious workaround of this is to replace
IoCancelFileOpen()
by sending CleanUp and Close by myself as if old versions.
But I wonder if there is a better solution.

Ichiro Akimoto

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

Ichiro_Akimoto-2 · June 16, 2005, 12:45pm

Thanks for the quick and usefull reply.
And I’m sorry for the too late reporting.
This is a somewhat deeper report of the problem.

I observed unbalanced Create/Close on WXP SP2 or its equivalent.
This occurs when you try to delete the file on the removable disk and
the filter driver issues IoCancelFileOpen() internally and denys it.
This problem is between OS and a filter driver only. No Anti-virus.
The Irps flow like below.
The final Create ends without Close.

(explorer SHIFT+DEL)
Create -> Filter driver --(Create)------> Filesystem
STATUS_SUCCESS <--------------
IoCancelFileOpen --(CleanUp)–>
<- STATUS_ACCESS_DENIED
Close -> Filter Driver --(Close)------->
<- STATUS_SUCCESS ----------------
Create -> Filter driver --(Create)------> Filesystem
STATUS_SUCCESS <--------------
IoCancelFileOpen --(CleanUp)–>
<- STATUS_ACCESS_DENIED
Close -> Filter Driver --(Close)------->
<- STATUS_SUCCESS ----------------
(*1)Create -> Filter driver --(Create)------> Filesystem
STATUS_SUCCESS <--------------
IoCancelFileOpen --(CleanUp)–>
<- STATUS_ACCESS_DENIED

The final(*1) Create comes from NtQueryAttributesFile() with a fake File
Object on the stack.
On WXP SP2 IoCancelFileOpen() does’nt issue Close.
Close is isssued when the reference count becomes zero.
But in case of a fake File Object Close is not issued if the Create ends
with an error.
i.e. STATUS_ACCESS_DENIED
So Create from a fake Object Close can not be IoCancelFileOpen().

I’m planning the two scenarios of workaround.
(1) In case of a fake File Object the filter driver doesn’t deny it.
In my own case this may be OK because the use of a fake File Object
is restricted as below.
NtDeleteFile()
NtQueryAttributesFile()
NtQueryFullAttributesFile()
IoFastQueryNetworkAttributes()
Hoping others don’t use a fake File Object in anyother way.
(2) In case the above does’nt work I implement my IoCancelFileOpen() and
call it only in case of a fake File Object.
Hoping others make no dangling reference.

Thank you.
Ichiro Akimoto
-----Original Message-----
“Tony Mason” wrote in message news:xxxxx@ntfsd…
See http://www.osronline.com/article.cfm?id=219. There are valid
reasons for not sending the IRP_MJ_CLOSE down; your mistake is in
assuming no other filter has used the file object in the interim, which
is not guaranteed to be correct.

I recently had to assist in debugging such a situation - you can read
about it http://www.osronline.com/article.cfm?article=379. This is an
explanation of why the solution you described doesn’t work properly, and
why IoCancelFileOpen was changed.

Regards,

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ichiro Akimoto
Sent: Tuesday, May 31, 2005 12:19 PM
To: ntfsd redirect
Subject: [ntfsd] wxp SP2 IoCancelFileOpen Change and problem

I observed that the internal protocol of IoCancelFileOpen() changed by
WXP
SP2.

In older versions IoCancelFileOpen() sends IRP_MJ_CLEANUP and
IRP_MJ_CLOSE.

In WXP SP2 IoCancelFileOpen() sends only IRP_MJ_CLEANUP.
If the reference count of the file object is reduced to zero
IRP_MJ_CLOSE is sent by IoManager.(I Think.)
This changes the flow of IRP_MJ_CREAT and IRP_MJ_CLOSE that a filter
driver
sees.

ex.
In older versions
Create -> Filter driver —(Create)-----> Filesystem
STATUS_SUCESS <---------------
IoCancelFileOpen --(CleanUp)–>
--(Close)---->
<- STATUS_ACCESS_DENIED(Filtrer driver generates)
In WXP SP2
Create -> Filter driver —(Create)-----> Filesystem
STATUS_SUCESS <---------------
IoCancelFileOpen --(CleanUp)–>
<- STATUS_ACCESS_DENIED(Filter driver generates)
Close —> ----->

My first question is:
Is this change a well-known fact? Is this a fix of something or new
feature?

I also observed the case Creates and Closes don’t balance in WXP SP2.
If a filter driver fails Create after sending down it and cancel it
by IoCancelFileOpen() in case of file deletion.

ex.
(explorer SHIFT+DEL)
Create -> Filter driver --(Create)------> Filesystem
STATUS_SUCCESS <--------------
IoCancelFileOpen --(CleanUp)–>
<- STATUS_ACCESS_DENIED
Close -> Filter Driver --(Close)------->
<- STATUS_SUCCESS ----------------
Create -> Filter driver --(Create)------> Filesystem
(Retry) STATUS_SUCCESS <--------------
IoCancelFileOpen --(CleanUp)–>
<- STATUS_ACCESS_DENIED
Close -> Filter Driver --(Close)------->
<- STATUS_SUCCESS ----------------
Create -> Filter driver --(Create)------> Filesystem
(Retry) STATUS_SUCCESS <--------------
IoCancelFileOpen --(CleanUp)–>
<- STATUS_ACCESS_DENIED

An external symptom of this is:
If the target of Create is a file in the removable media
you can’t safely remove the device because of the lost Close.
But you can open the file after it because CleanUp has been finished.

My second question is:
Is this a bug of IoManager or something known?
Does someone have the same experience?
If it is a bug one obvious workaround of this is to replace
IoCancelFileOpen()
by sending CleanUp and Close by myself as if old versions.
But I wonder if there is a better solution.

Ichiro Akimoto

—
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

OSR_Community_User · June 17, 2005, 12:42am

Ichiro,

This is a known bug that was found and fixed after XP SP2 was released.
This is already fixed in Srv03 SP1 and will be fixed in XP SP3.

There is a hotfix available that fixes this bug. Check out KB article
#885443. Though it does not explicitly state it in the KB article, your
issue is fixed with this hotfix.

Neal Christiansen
Microsoft File System Filter Group Lead
This posting is provided “AS IS” with no warranties, and confers no
Rights

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ichiro Akimoto
Sent: Thursday, June 16, 2005 9:45 AM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] wxp SP2 IoCancelFileOpen Change and problem

Thanks for the quick and usefull reply.
And I’m sorry for the too late reporting.
This is a somewhat deeper report of the problem.

I observed unbalanced Create/Close on WXP SP2 or its equivalent.
This occurs when you try to delete the file on the removable disk and
the filter driver issues IoCancelFileOpen() internally and denys it.
This problem is between OS and a filter driver only. No Anti-virus.
The Irps flow like below.
The final Create ends without Close.

(explorer SHIFT+DEL)
Create -> Filter driver --(Create)------> Filesystem
STATUS_SUCCESS <--------------
IoCancelFileOpen --(CleanUp)–>
<- STATUS_ACCESS_DENIED
Close -> Filter Driver --(Close)------->
<- STATUS_SUCCESS ----------------
Create -> Filter driver --(Create)------> Filesystem
STATUS_SUCCESS <--------------
IoCancelFileOpen --(CleanUp)–>
<- STATUS_ACCESS_DENIED
Close -> Filter Driver --(Close)------->
<- STATUS_SUCCESS ----------------
(*1)Create -> Filter driver --(Create)------> Filesystem
STATUS_SUCCESS <--------------
IoCancelFileOpen --(CleanUp)–>
<- STATUS_ACCESS_DENIED

The final(*1) Create comes from NtQueryAttributesFile() with a fake File

Object on the stack.
On WXP SP2 IoCancelFileOpen() does’nt issue Close.
Close is isssued when the reference count becomes zero.
But in case of a fake File Object Close is not issued if the Create ends

with an error.
i.e. STATUS_ACCESS_DENIED
So Create from a fake Object Close can not be IoCancelFileOpen().

I’m planning the two scenarios of workaround.
(1) In case of a fake File Object the filter driver doesn’t deny it.
In my own case this may be OK because the use of a fake File Object
is restricted as below.
NtDeleteFile()
NtQueryAttributesFile()
NtQueryFullAttributesFile()
IoFastQueryNetworkAttributes()
Hoping others don’t use a fake File Object in anyother way.
(2) In case the above does’nt work I implement my IoCancelFileOpen()
and
call it only in case of a fake File Object.
Hoping others make no dangling reference.

Thank you.
Ichiro Akimoto
-----Original Message-----
“Tony Mason” wrote in message news:xxxxx@ntfsd…
See http://www.osronline.com/article.cfm?id=219. There are valid
reasons for not sending the IRP_MJ_CLOSE down; your mistake is in
assuming no other filter has used the file object in the interim, which
is not guaranteed to be correct.

I recently had to assist in debugging such a situation - you can read
about it http://www.osronline.com/article.cfm?article=379. This is an
explanation of why the solution you described doesn’t work properly, and
why IoCancelFileOpen was changed.

Regards,

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ichiro Akimoto
Sent: Tuesday, May 31, 2005 12:19 PM
To: ntfsd redirect
Subject: [ntfsd] wxp SP2 IoCancelFileOpen Change and problem

I observed that the internal protocol of IoCancelFileOpen() changed by
WXP
SP2.

In older versions IoCancelFileOpen() sends IRP_MJ_CLEANUP and
IRP_MJ_CLOSE.

In WXP SP2 IoCancelFileOpen() sends only IRP_MJ_CLEANUP.
If the reference count of the file object is reduced to zero
IRP_MJ_CLOSE is sent by IoManager.(I Think.)
This changes the flow of IRP_MJ_CREAT and IRP_MJ_CLOSE that a filter
driver
sees.

ex.
In older versions
Create -> Filter driver —(Create)-----> Filesystem
STATUS_SUCESS <---------------
IoCancelFileOpen --(CleanUp)–>
--(Close)---->
<- STATUS_ACCESS_DENIED(Filtrer driver generates)
In WXP SP2
Create -> Filter driver —(Create)-----> Filesystem
STATUS_SUCESS <---------------
IoCancelFileOpen --(CleanUp)–>
<- STATUS_ACCESS_DENIED(Filter driver generates)
Close —> ----->

My first question is:
Is this change a well-known fact? Is this a fix of something or new
feature?

I also observed the case Creates and Closes don’t balance in WXP SP2.
If a filter driver fails Create after sending down it and cancel it
by IoCancelFileOpen() in case of file deletion.

ex.
(explorer SHIFT+DEL)
Create -> Filter driver --(Create)------> Filesystem
STATUS_SUCCESS <--------------
IoCancelFileOpen --(CleanUp)–>
<- STATUS_ACCESS_DENIED
Close -> Filter Driver --(Close)------->
<- STATUS_SUCCESS ----------------
Create -> Filter driver --(Create)------> Filesystem
(Retry) STATUS_SUCCESS <--------------
IoCancelFileOpen --(CleanUp)–>
<- STATUS_ACCESS_DENIED
Close -> Filter Driver --(Close)------->
<- STATUS_SUCCESS ----------------
Create -> Filter driver --(Create)------> Filesystem
(Retry) STATUS_SUCCESS <--------------
IoCancelFileOpen --(CleanUp)–>
<- STATUS_ACCESS_DENIED

An external symptom of this is:
If the target of Create is a file in the removable media
you can’t safely remove the device because of the lost Close.
But you can open the file after it because CleanUp has been finished.

My second question is:
Is this a bug of IoManager or something known?
Does someone have the same experience?
If it is a bug one obvious workaround of this is to replace
IoCancelFileOpen()
by sending CleanUp and Close by myself as if old versions.
But I wonder if there is a better solution.

Ichiro Akimoto

—
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: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com