5903 SMB server breaks an oplock on after an attribute (only) open
Review Request #46 — Created May 2, 2015 and submitted
We were needlessly revoking cache state (sending an "oplock break") in a case where a new client open had access rights that only allowed attribute changes. We're not supposed to revoke cache delegations in such a case.
There was also some poorly ordered logic in smb_open_subr() which we fixed while looking at this.
The general order of things should be: (a) access checks, (b) oplock breaking, (c) share modes, (d) actually create etc.
Author: Alek Pinchuk
Samba "smbtorture" oplock tests.
Field tested for quite some time.