Multiple filters using FILE_OPEN_REQURING_OPLOCK

NTFSD
1

Hi,

We’re trying to debug an interop issue where we call FltCreateFile2 with the FILE_OPEN_REQURING_OPLOCK flag but still see a 35 second timeout. My understanding is that if the file is oplocked, the call should return immediately with STATUS_CANNOT_BREAK_OPLOCK.

We’re spinning theories at this point. I’m wondering what would happen if another filter opens the same file with FILE_OPEN_REQURING_OPLOCK and then keeps the handle open but does not request the oplock. Would our CREATE be pended for some finite length of time?

The docs allude to something like this but don’t go into specifics:

“An application that uses this flag [FILE_OPEN_REQURING_OPLOCK] must request an oplock after this call succeeds, or all subsequent attempts to open the file will be blocked without the benefit of normal oplock processing.”

https://msdn.microsoft.com/en-us/library/bb432380(v=vs.85).aspx

Thank you,
Alnoor

2

If you don’t actually request the oplock after, then applications opening
the file *without* FILE_OPEN_REQUIRING_OPLOCK would block. I’d expect
applications that try to open with FILE_OPEN_REQUIRING_OPLOCK to fail
immediately though (easily validated with two copies of FileTest).

Have you done any analysis of the hanging threads yet?

-scott
OSR
@OSRDrivers

wrote in message news:xxxxx@ntfsd…

Hi,

We’re trying to debug an interop issue where we call FltCreateFile2 with the
FILE_OPEN_REQURING_OPLOCK flag but still see a 35 second timeout. My
understanding is that if the file is oplocked, the call should return
immediately with STATUS_CANNOT_BREAK_OPLOCK.

We’re spinning theories at this point. I’m wondering what would happen if
another filter opens the same file with FILE_OPEN_REQURING_OPLOCK and then
keeps the handle open but does not request the oplock. Would our CREATE be
pended for some finite length of time?

The docs allude to something like this but don’t go into specifics:

“An application that uses this flag [FILE_OPEN_REQURING_OPLOCK] must request
an oplock after this call succeeds, or all subsequent attempts to open the
file will be blocked without the benefit of normal oplock processing.”

https://msdn.microsoft.com/en-us/library/bb432380(v=vs.85).aspx

Thank you,
Alnoor

3

Hi Scott,

FileTest didn’t occur to me for some reason and I didn’t have time to test the theory out with multiple kernel callers.

In any case, the theory appears to be debunked. It looks like one of the other filters is doing some post-callback processing that is slowing down the system.

I’ll play around with FileTest and FILE_OPEN_REQUIRING_OPLOCK for future reference.

Thanks!
Alnoor