Thanks for the replies.
It turns out that the IRP_MJ_CLOSE *is* being issued, however, it is
associated with a different process than the one that performed the
IRP_MJ_CREATE. Is this normal?
Thanks for the replies.
It turns out that the IRP_MJ_CLOSE *is* being issued, however, it is
associated with a different process than the one that performed the
IRP_MJ_CREATE. Is this normal?
Yes.
It is because of Cc na/or Mm referencing for cached files.
Thus when the last reference has gone - because of Mm’s or
Cc’s issued ObDereferenceObject - there is IRP_MJ_CLOSE
sent to File system. This is almost done in some system
thread context.
Paul
-----P?vodn? zpr?va-----
Od: Neil Weicher [SMTP:xxxxx@netlib.com]
Odesl?no: 4. kv?tna 2000 13:44
Komu: File Systems Developers
Kopie: xxxxx@pandasoftware.es
P?edm?t: [ntfsd] RE: Close without IRP_MJ_CLOSEThanks for the replies.
It turns out that the IRP_MJ_CLOSE *is* being issued, however, it is
associated with a different process than the one that performed the
IRP_MJ_CREATE. Is this normal?
You are currently subscribed to ntfsd as: xxxxx@sodatsw.cz
To unsubscribe send a blank email to $subst(‘Email.Unsub’)