Can I determine if an IRP_MJ_CLOSE request is for the entire volume or a file or directory in an fs

Can I determine if an IRP_MJ_CLOSE request is for the entire volume or a
file or directory in an fs filter close dispatch, or do I have to cache the
information about which file objects represent the entire volume when I get
a create request for them?

I’m running into the problem described in the Nov/Dec 2000 NT Insider in the
article “Filtering the Riff-Raff - Observations on File System Filter
Drivers” with removable media. I get a close request, set a completion
routine for it and pass it down to the fs. The fs then calls my fast io
detatch and I delete the device. It then completes the close request and my
completion routine is invoked. I then access information in the device
extension for the now deleted DO and get a BSOD. I can avoid this, because
I don’t need the completion routine for volume closes.
I can cache the information for file objects on create, to determine this,
but it would be nice if I could determine this from the file object at close
time.

Or, is there another way around this by still using a completion routine?
The problem with the completion routine is that this is all happening in the
same thread. If I determine that I have this outstanding close request
while I’m in my detach routine, I can’t wait for the request to complete,
because the close request won’t be completed until I return from my detach
routine. Is it OK to not delete the device in my detach routine, return and
then wait until my completion routine to delete the device? I think that
might be what the OSR arcticle is implying, but I’t didn’t seem clear.

Thanks,

Jonathan

Jonathan,

The solution we implement traditionally at OSR is to defer deletion of
our device object until the completion routine. Our implementation of
this is by using a reference counting model (+1 for the attach, +1 for
each IRP we send down, then -1 on detach, and -1 in the completion
routine). We delete the device object when the reference count drops to
zero. Effectively, this means that in the case you are observing the
deletion occurs in the completion routine. I wouldn’t have said “delete
it in completion” because the implementation we chose is tied to
outstanding references, not a specific operation.

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 Jonathan Ludwig
Sent: Wednesday, December 22, 2004 7:27 PM
To: ntfsd redirect
Subject: [ntfsd] Can I determine if an IRP_MJ_CLOSE request is for the
entire volume or a file or directory in an fs filter close dispatch?

Can I determine if an IRP_MJ_CLOSE request is for the entire volume or a

file or directory in an fs filter close dispatch, or do I have to cache
the
information about which file objects represent the entire volume when I
get
a create request for them?

I’m running into the problem described in the Nov/Dec 2000 NT Insider in
the
article “Filtering the Riff-Raff - Observations on File System Filter
Drivers” with removable media. I get a close request, set a completion
routine for it and pass it down to the fs. The fs then calls my fast io

detatch and I delete the device. It then completes the close request
and my
completion routine is invoked. I then access information in the device
extension for the now deleted DO and get a BSOD. I can avoid this,
because
I don’t need the completion routine for volume closes.
I can cache the information for file objects on create, to determine
this,
but it would be nice if I could determine this from the file object at
close
time.

Or, is there another way around this by still using a completion
routine?
The problem with the completion routine is that this is all happening in
the
same thread. If I determine that I have this outstanding close request
while I’m in my detach routine, I can’t wait for the request to
complete,
because the close request won’t be completed until I return from my
detach
routine. Is it OK to not delete the device in my detach routine, return
and
then wait until my completion routine to delete the device? I think
that
might be what the OSR arcticle is implying, but I’t didn’t seem clear.

Thanks,

Jonathan


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

Jonathon,

What OS version were you seeing this on? I am guessing it was W2K and
earlier.

It is unfortunate that we had file systems (like fat) which would delete
its device object before the close was completed. This bug was fixed in
the kernel in XP and later so it will address other file systems besides
FAT that do this. This will be fixed in W2K SP4 when the Security
Rollup (SRP) is released later this year.

For those that have to run on OS’s where this is not fixed Tony’s
workaround is a good one. Minifilters do not need to worry about this.

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 Tony Mason
Sent: Thursday, December 23, 2004 4:33 AM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] Can I determine if an IRP_MJ_CLOSE request is for
the entire volume or a file or directory in an fs filter close dispatch?

Jonathan,

The solution we implement traditionally at OSR is to defer deletion of
our device object until the completion routine. Our implementation of
this is by using a reference counting model (+1 for the attach, +1 for
each IRP we send down, then -1 on detach, and -1 in the completion
routine). We delete the device object when the reference count drops to
zero. Effectively, this means that in the case you are observing the
deletion occurs in the completion routine. I wouldn’t have said “delete
it in completion” because the implementation we chose is tied to
outstanding references, not a specific operation.

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 Jonathan Ludwig
Sent: Wednesday, December 22, 2004 7:27 PM
To: ntfsd redirect
Subject: [ntfsd] Can I determine if an IRP_MJ_CLOSE request is for the
entire volume or a file or directory in an fs filter close dispatch?

Can I determine if an IRP_MJ_CLOSE request is for the entire volume or a

file or directory in an fs filter close dispatch, or do I have to cache
the
information about which file objects represent the entire volume when I
get
a create request for them?

I’m running into the problem described in the Nov/Dec 2000 NT Insider in
the
article “Filtering the Riff-Raff - Observations on File System Filter
Drivers” with removable media. I get a close request, set a completion
routine for it and pass it down to the fs. The fs then calls my fast io

detatch and I delete the device. It then completes the close request
and my
completion routine is invoked. I then access information in the device
extension for the now deleted DO and get a BSOD. I can avoid this,
because
I don’t need the completion routine for volume closes.
I can cache the information for file objects on create, to determine
this,
but it would be nice if I could determine this from the file object at
close
time.

Or, is there another way around this by still using a completion
routine?
The problem with the completion routine is that this is all happening in
the
same thread. If I determine that I have this outstanding close request
while I’m in my detach routine, I can’t wait for the request to
complete,
because the close request won’t be completed until I return from my
detach
routine. Is it OK to not delete the device in my detach routine, return
and
then wait until my completion routine to delete the device? I think
that
might be what the OSR arcticle is implying, but I’t didn’t seem clear.

Thanks,

Jonathan


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