SAMBA Project Documentation
Prev		Next

Chapter 3. Oplocks

3.1. What are oplocks?

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.

Prev	Home	Next
Improved browsing in samba	Up	Quick Cross Subnet Browsing / Cross Workgroup Browsing guide