[Samba] oplocks and share modes

[John Gerth]

Ok, as promised, a brief explaination of oplocks, share modes
and locking.

When a client opens a file it can request an "oplock" or file
lease. This is (to simplify a bit) a guarentee that no one else
has the file open simultaneously. It allows the client to not
send any updates on the file to the server, thus reducing a
network file access to local access (once the file is in
client cache). An "oplock break" is when the server sends
a request to the client to flush all its changes back to
the server, so the file is in a consistent state for other
opens to succeed. If a client fails to respond to this
asynchronous request then the file can be corrupted. Hence
the "turn off oplocks" answer if people are having multi-user
file access problems.

Unless the kernel is "oplock aware" (SGI IRIX and Linux are
the only two UNIXes that are at the moment) then if a local
UNIX process accesses the file simultaneously then Samba
has no way of telling this is occuring, so the guarentee
to the client is broken. This can corrupt the file. Short
answer - it you have UNIX clients accessing the same file
as smbd locally or via NFS and you're not running Linux or
IRIX then turn off oplocks for that file or share.

"Share modes". These are modes of opening a file, that
guarentee an invarient - such as DENY_WRITE - which means
that if any other opens are requested with write access after
this current open has succeeded then they should be denied
with a "sharing violation" error message. Samba handles these
internally inside smbd. UNIX clients accessing the same file
ignore these invarients. Just proving that if you need simultaneous
file access from a Windows and UNIX client you *must* have an
application that is written to lock records correctly on both
sides. Few applications are written like this, and even fewer
are cross platform (UNIX and Windows) so in practice this isn't
much of a problem.

"Locking". This really means "byte range locking" - such as
lock 10 bytes at file offset 24 for write access. This is the
area in which well written UNIX and Windows apps will cooperate.
Windows locks (at least from NT or above) are 64-bit unsigned
offsets. UNIX locks are either 31 bit or 63 bit and are signed
(the top bit is used for the sign). Samba handles these by
first ensuring that all the Windows locks don't conflict (ie.
if other Windows clients have competing locks then just reject
immediately) - this allows us to support 64-bit Windows locks
on 32-bit filesystems. Secondly any locks that are valid are
then mapped onto UNIX fcntl byte range locks. These are the
locks that will be seen by UNIX processes. If there is a conflict
here the lock is rejected.

Note that if a client has an oplock then it "knows" that no
other client can have the file open so usually doesn't bother
to send to lock request to the server - this means once again
if you need to share files between UNIX and Windows processes
either use IRIX or Linux, or turn off oplocks for these
files/shares.

Hope this is clear :-).

Jeremy.