1 files changed, 208 insertions, 0 deletions
diff --git a/docs/htmldocs/oplocks.html b/docs/htmldocs/oplocks.html
new file mode 100644
index 0000000000..c926f32c14
--- /dev/null
+++ b/docs/htmldocs/oplocks.html
@@ -0,0 +1,208 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
+<HTML
+><HEAD
+><TITLE
+>Oplocks</TITLE
+><META
+NAME="GENERATOR"
+CONTENT="Modular DocBook HTML Stylesheet Version 1.77"><LINK
+REL="HOME"
+TITLE="SAMBA Project Documentation"
+HREF="samba-howto-collection.html"><LINK
+REL="UP"
+TITLE="General installation"
+HREF="p18.html"><LINK
+REL="PREVIOUS"
+TITLE="Improved browsing in samba"
+HREF="improved-browsing.html"><LINK
+REL="NEXT"
+TITLE="Quick Cross Subnet Browsing / Cross Workgroup Browsing guide"
+HREF="browsing-quick.html"></HEAD
+><BODY
+CLASS="CHAPTER"
+BGCOLOR="#FFFFFF"
+TEXT="#000000"
+LINK="#0000FF"
+VLINK="#840084"
+ALINK="#0000FF"
+><DIV
+CLASS="NAVHEADER"
+><TABLE
+SUMMARY="Header navigation table"
+WIDTH="100%"
+BORDER="0"
+CELLPADDING="0"
+CELLSPACING="0"
+><TR
+><TH
+COLSPAN="3"
+ALIGN="center"
+>SAMBA Project Documentation</TH
+></TR
+><TR
+><TD
+WIDTH="10%"
+ALIGN="left"
+VALIGN="bottom"
+><A
+HREF="improved-browsing.html"
+ACCESSKEY="P"
+>Prev</A
+></TD
+><TD
+WIDTH="80%"
+ALIGN="center"
+VALIGN="bottom"
+></TD
+><TD
+WIDTH="10%"
+ALIGN="right"
+VALIGN="bottom"
+><A
+HREF="browsing-quick.html"
+ACCESSKEY="N"
+>Next</A
+></TD
+></TR
+></TABLE
+><HR
+ALIGN="LEFT"
+WIDTH="100%"></DIV
+><DIV
+CLASS="CHAPTER"
+><H1
+><A
+NAME="OPLOCKS"
+></A
+>Chapter 3. Oplocks</H1
+><DIV
+CLASS="SECT1"
+><H1
+CLASS="SECT1"
+><A
+NAME="AEN377"
+></A
+>3.1. What are oplocks?</H1
+><P
+>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.</P
+><P
+>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.</P
+><P
+>"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.</P
+><P
+>"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.</P
+><P
+>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.</P
+></DIV
+></DIV
+><DIV
+CLASS="NAVFOOTER"
+><HR
+ALIGN="LEFT"
+WIDTH="100%"><TABLE
+SUMMARY="Footer navigation table"
+WIDTH="100%"
+BORDER="0"
+CELLPADDING="0"
+CELLSPACING="0"
+><TR
+><TD
+WIDTH="33%"
+ALIGN="left"
+VALIGN="top"
+><A
+HREF="improved-browsing.html"
+ACCESSKEY="P"
+>Prev</A
+></TD
+><TD
+WIDTH="34%"
+ALIGN="center"
+VALIGN="top"
+><A
+HREF="samba-howto-collection.html"
+ACCESSKEY="H"
+>Home</A
+></TD
+><TD
+WIDTH="33%"
+ALIGN="right"
+VALIGN="top"
+><A
+HREF="browsing-quick.html"
+ACCESSKEY="N"
+>Next</A
+></TD
+></TR
+><TR
+><TD
+WIDTH="33%"
+ALIGN="left"
+VALIGN="top"
+>Improved browsing in samba</TD
+><TD
+WIDTH="34%"
+ALIGN="center"
+VALIGN="top"
+><A
+HREF="p18.html"
+ACCESSKEY="U"
+>Up</A
+></TD
+><TD
+WIDTH="33%"
+ALIGN="right"
+VALIGN="top"
+>Quick Cross Subnet Browsing / Cross Workgroup Browsing guide</TD
+></TR
+></TABLE
+></DIV
+></BODY
+></HTML
+>
+\ No newline at end of file