Although I’ve NEVER encountered a STATUS_PENDING return value in
IRP_MJ_CREATE, as I see it’s possible.
Now, this poses a small problem.
For local drives, Irp->IoStatus.Information will contain
FILE_OPENED, FILE_CREATED etc. the information about what was actually
done, so if the CreateDisposition was FILE_OPEN_IF, I can know what
really happened.
On network drives, and network paths, this is not true, however,
and this field is always zeroed!
So, the only way to handle this was to split the Irp - first
send a changed Irp with CreateDisposition set to FILE_OPEN and then
FILE_CREATE, if FILE_OPEN failed. To do this, I returned
STATUS_MORE_PROCESSING_REQUIRED in completion routine, if the
Irp->IoStatus.Status says the operation failed, and resend the Irp in
the dispatch routine, with FILE_CREATE.
However, in case when STATUS_PENDING is returned, this won’t
work, and what’s worse the system would lockup:-)
Now, has anyone been down this road before, and can tell me the
right way to handle this?
My idea would be to:

  • In dispatch return the status IoCallDriver returned.
  • In completion, if the Irp->IoStatus.Status is successful, just
    return it
  • If not, then setup a work item, and return
  • In the work routine, resend the Irp with FILE_CREATE this

Does anyone see any pitfalls in this, or is there anything else
I should worry about?

Kind regards, Dejan M. CEO Alfa Co.
ICQ#: 56570367
Professional file&system related components and libraries for Win32
Alfa File Monitor - #1 file monitoring system for Win32 developers.
Alfa File Protector - #1 file protection and hiding system for Win32
Alfa Units - #1 file and system handling units for Delphi.

You are currently subscribed to ntfsd as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)