oplock is lost on timeout

[Jeremy Allison]

tridge at linuxcare.com wrote:
> 
> Jeremy,
> 
> The next test I did was the following:
> 
> open with oplock
> unlink
>   break sent
>   break request timed out after 45 secs
> unlink fails with ERRbadshare
> unlink
> unlink fails immediately
> 
> this shows that the NT4 server considers the oplock lost after the
> timeout (otherwise we would have gotten a second break request after
> the second unlink) but that it still considers the file open
> (otherwise the unlink would have succeeded)

Yea - this corresponds with the registry variable
(sort of - the description there implies the file
is closed, but your tests imply it just silently
drops the oplock). The problem with this is that
it'll silently cause file corruption as the oplock
data is never flushed....

Hmmmmmm. What if the client doesn't *have* any
outstanding data to flush and in this case goes into a
buggy code path where it doesn't bother responding.

If the MS server coders knew this, they could correctly
just drop the oplock in the case of non response,
and not risk file corruption. In this case it would
be a client bug, but a benign one (other than the
delay) in the view of the MS server coders.

It may be that NT gets just as many failures
to respond as we do, it's just that we're paranoid
about it and abort, and they know it isn't really a
problem.

It's a risky strategy to try out though......

Jeremy.

-- 
--------------------------------------------------------
Buying an operating system without source is like buying
a self-assembly Space Shuttle with no instructions.
--------------------------------------------------------