Filter driver oplock handling 101

NTFSD
1

Here is my attempt to distill about a dozen pages of NT filesystem
oplock handling documentation (from three different sources) into two
simple rules for filesystem filter drivers to follow if they wish to be
compatible:

  1. If you filter an IRP_MJ_CREATE request, and the return value is
    STATUS_OPLOCK_BREAK_IN_PROGRESS, you can still track the file based on
    the value of FileObject->FsContext, but you cannot READ or WRITE from
    the file until the oplock break has been completed. (You also assume
    nobody else will read or write from the file as well). So if your filter
    must perform post-processing of a file after IRP_MJ_CREATE, and this
    post-processing involves reads or writes, you must delay the
    post-processing until after the break.

  2. You know the break has been completed when you see an
    FSCTL_OPLOCK_BREAK_NOTIFY filesystem control request with the same
    FileObject->FsContext that you had to delay post-processing on in step

  3. In this case, you wait for the FSCTL_OPLOCK_BREAK_NOTIFY to complete,
    and if the completion code is STATUS_SUCCESS, you can now safely perform
    your filter post-processing.

Am I even close?

  • Nicholas Ryan

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