Delayed IRP_MJ_CLOSE

NTFSD
1

Hi, all

I’m solving a problem coming from delayed close in our filter.
If the filter cannot acquire VCB exclusively, it will queue the close.
Well. Looking into the FastFat example in IFS kit 2003
(Author of our filter took these sources as start point)
there is a possibility that FatCommonClose returns
STATUS_PENDING. In this case, FASTFAT queues the
request, then completes it (FatCompleteRequest)
and returns STATUS_SUCCESS.

It it OK to return STATUS_SUCCESS instead of STATUS_PENDING ?

I think the FS should queue the request, mark the IRP as pending,
and then return STATUS_PENDING without completing it
(which will be done later when worker thread completes the
close operation).

Or am I wrong ?

L.

2

I am not sure I understand your question.

The fact that FAT internally delays the actual processing of the close
IRP to some later time is immaterial to filters. FAT completed the IRP
and returned STATUS_SUCCESS so you need to process the IRP like it was
completed.

If a filter receives STATUS_PENDING in its dispatch routine from a lower
level filter/file system it is required to return STATUS_PENDING itself
unless it synchronizes back to its dispatch routine.

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 Ladislav Zezula
Sent: Monday, March 15, 2004 3:14 AM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] Delayed IRP_MJ_CLOSE

Hi, all

I’m solving a problem coming from delayed close in our filter.
If the filter cannot acquire VCB exclusively, it will queue the close.
Well. Looking into the FastFat example in IFS kit 2003
(Author of our filter took these sources as start point)
there is a possibility that FatCommonClose returns
STATUS_PENDING. In this case, FASTFAT queues the
request, then completes it (FatCompleteRequest)
and returns STATUS_SUCCESS.

It it OK to return STATUS_SUCCESS instead of STATUS_PENDING ?

I think the FS should queue the request, mark the IRP as pending,
and then return STATUS_PENDING without completing it
(which will be done later when worker thread completes the
close operation).

Or am I wrong ?

L.

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

3

> The fact that FAT internally delays the actual processing of the close

IRP to some later time is immaterial to filters.

Yes. In our filter, the logic is taken from FASTFAT.
We have our own volume control block, and we
acquire it before some operations (e.g. create and close).

If the VCB cannot be acquired, our filter delays the close request.
And here comes the problem.

  • If the filter return STATUS_PENDING,
    saves the IRP and completes it in our worker thread, it causes deadlock
    in cooperation with some older version of Norton Antivirus on NT 4.0,
    even if we properly set the Irp->UserEvent which I/O manager
    waits for.

If our filter returns STATUS_SUCCESS and delay the close, the file
cannot be opened a little time after it’s been closed (our close handler
must dereference a file object created during IRP_MJ_CREATE).

So the question is - If a filter needs to delay processing of the close
request,
should it

  1. Mark IRP as pending
  2. Return STATUS_PENDING
  3. (in worker thread) complete the close operation
  4. (in worker thread) complete the IRP
  5. (in worker thread) set the Irp->UserEvent

?

L.