1 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
8 CONTENT="Modular DocBook HTML Stylesheet Version 1.77"><LINK
10 TITLE="SAMBA Project Documentation"
11 HREF="samba-howto-collection.html"><LINK
13 TITLE="General installation"
14 HREF="introduction.html"><LINK
16 TITLE="Improved browsing in samba"
17 HREF="improved-browsing.html"><LINK
19 TITLE="Quick Cross Subnet Browsing / Cross Workgroup Browsing guide"
20 HREF="browsing-quick.html"></HEAD
31 SUMMARY="Header navigation table"
40 >SAMBA Project Documentation</TH
48 HREF="improved-browsing.html"
62 HREF="browsing-quick.html"
77 >Chapter 3. Oplocks</H1
85 >3.1. What are oplocks?</H1
87 >When a client opens a file it can request an "oplock" or file
88 lease. This is (to simplify a bit) a guarentee that no one else
89 has the file open simultaneously. It allows the client to not
90 send any updates on the file to the server, thus reducing a
91 network file access to local access (once the file is in
92 client cache). An "oplock break" is when the server sends
93 a request to the client to flush all its changes back to
94 the server, so the file is in a consistent state for other
95 opens to succeed. If a client fails to respond to this
96 asynchronous request then the file can be corrupted. Hence
97 the "turn off oplocks" answer if people are having multi-user
98 file access problems.</P
100 >Unless the kernel is "oplock aware" (SGI IRIX and Linux are
101 the only two UNIXes that are at the moment) then if a local
102 UNIX process accesses the file simultaneously then Samba
103 has no way of telling this is occuring, so the guarentee
104 to the client is broken. This can corrupt the file. Short
105 answer - it you have UNIX clients accessing the same file
106 as smbd locally or via NFS and you're not running Linux or
107 IRIX then turn off oplocks for that file or share.</P
109 >"Share modes". These are modes of opening a file, that
110 guarentee an invarient - such as DENY_WRITE - which means
111 that if any other opens are requested with write access after
112 this current open has succeeded then they should be denied
113 with a "sharing violation" error message. Samba handles these
114 internally inside smbd. UNIX clients accessing the same file
115 ignore these invarients. Just proving that if you need simultaneous
116 file access from a Windows and UNIX client you *must* have an
117 application that is written to lock records correctly on both
118 sides. Few applications are written like this, and even fewer
119 are cross platform (UNIX and Windows) so in practice this isn't
120 much of a problem.</P
122 >"Locking". This really means "byte range locking" - such as
123 lock 10 bytes at file offset 24 for write access. This is the
124 area in which well written UNIX and Windows apps will cooperate.
125 Windows locks (at least from NT or above) are 64-bit unsigned
126 offsets. UNIX locks are either 31 bit or 63 bit and are signed
127 (the top bit is used for the sign). Samba handles these by
128 first ensuring that all the Windows locks don't conflict (ie.
129 if other Windows clients have competing locks then just reject
130 immediately) - this allows us to support 64-bit Windows locks
131 on 32-bit filesystems. Secondly any locks that are valid are
132 then mapped onto UNIX fcntl byte range locks. These are the
133 locks that will be seen by UNIX processes. If there is a conflict
134 here the lock is rejected.</P
136 >Note that if a client has an oplock then it "knows" that no
137 other client can have the file open so usually doesn't bother
138 to send to lock request to the server - this means once again
139 if you need to share files between UNIX and Windows processes
140 either use IRIX or Linux, or turn off oplocks for these
149 SUMMARY="Footer navigation table"
160 HREF="improved-browsing.html"
169 HREF="samba-howto-collection.html"
178 HREF="browsing-quick.html"
188 >Improved browsing in samba</TD
194 HREF="introduction.html"
202 >Quick Cross Subnet Browsing / Cross Workgroup Browsing guide</TD