Asynchronous IRP_MJ_CLEANUP/CLOSE processing.

NTFSD
1

In my filter driver I’ve seen many times that FSD return STATUS_PENDING in
response to IRP_MJ_CLOSE request. Do I gain something from implementing
asynchronous behaviour in my FSD/FSFD? My only guess is that Cc or Mm can
use this behaviour when, for example, flushing many sections at a time. Do I
gain something in asynchronous IRP_MJ_CLEANUP processing?

2

IIRC they are always sent as synchronous. For instance, CLOSE is the
semantics of C++ destructor for a file object.

Max

----- Original Message -----
From: “Alexey Logachyov”
To: “File Systems Developers”
Sent: Thursday, February 06, 2003 3:21 PM
Subject: [ntfsd] Asynchronous IRP_MJ_CLEANUP/CLOSE processing.

> In my filter driver I’ve seen many times that FSD return
STATUS_PENDING in
> response to IRP_MJ_CLOSE request. Do I gain something from
implementing
> asynchronous behaviour in my FSD/FSFD? My only guess is that Cc or
Mm can
> use this behaviour when, for example, flushing many sections at a
time. Do I
> gain something in asynchronous IRP_MJ_CLEANUP processing?
>
>
>
>
> —
> You are currently subscribed to ntfsd as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>