summaryrefslogtreecommitdiff
path: root/docs/docbook
diff options
context:
space:
mode:
authorJelmer Vernooij <jelmer@samba.org>2003-04-21 16:16:31 +0000
committerJelmer Vernooij <jelmer@samba.org>2003-04-21 16:16:31 +0000
commitc0ac957fc2f177f3349b8b763fbd54ade14da56c (patch)
tree793b16a103940e5d6f287212a006a4179355ae5f /docs/docbook
parent78476119faf62ace4f6cbda66b56d00aa63a5ed6 (diff)
downloadsamba-c0ac957fc2f177f3349b8b763fbd54ade14da56c.tar.gz
samba-c0ac957fc2f177f3349b8b763fbd54ade14da56c.tar.bz2
samba-c0ac957fc2f177f3349b8b763fbd54ade14da56c.zip
Move information about locking to seperate chapter and
information about scope id's to the faq (This used to be commit f2c333822f34be8a2bb85124319ead4dc44c2891)
Diffstat (limited to 'docs/docbook')
-rw-r--r--docs/docbook/projdoc/UNIX_INSTALL.sgml67
-rw-r--r--docs/docbook/projdoc/locking.sgml60
-rw-r--r--docs/docbook/projdoc/samba-doc.sgml1
3 files changed, 61 insertions, 67 deletions
diff --git a/docs/docbook/projdoc/UNIX_INSTALL.sgml b/docs/docbook/projdoc/UNIX_INSTALL.sgml
index 239ccd168b..1019e524f7 100644
--- a/docs/docbook/projdoc/UNIX_INSTALL.sgml
+++ b/docs/docbook/projdoc/UNIX_INSTALL.sgml
@@ -172,72 +172,5 @@
Samba has been successfully installed at thousands of sites worldwide,
so maybe someone else has hit your problem and has overcome it. </para>
- <sect2>
- <title>Scope IDs</title>
-
- <para>By default Samba uses a blank scope ID. This means
- all your windows boxes must also have a blank scope ID.
- If you really want to use a non-blank scope ID then you will
- need to use the 'netbios scope' smb.conf option.
- All your PCs will need to have the same setting for
- this to work. I do not recommend scope IDs.</para>
- </sect2>
-
- <sect2>
- <title>Locking</title>
-
- <para>One area which sometimes causes trouble is locking.</para>
-
- <para>There are two types of locking which need to be
- performed by a SMB server. The first is "record locking"
- which allows a client to lock a range of bytes in a open file.
- The second is the "deny modes" that are specified when a file
- is open.</para>
-
- <para>Record locking semantics under Unix is very
- different from record locking under Windows. Versions
- of Samba before 2.2 have tried to use the native
- fcntl() unix system call to implement proper record
- locking between different Samba clients. This can not
- be fully correct due to several reasons. The simplest
- is the fact that a Windows client is allowed to lock a
- byte range up to 2^32 or 2^64, depending on the client
- OS. The unix locking only supports byte ranges up to
- 2^31. So it is not possible to correctly satisfy a
- lock request above 2^31. There are many more
- differences, too many to be listed here.</para>
-
- <para>Samba 2.2 and above implements record locking
- completely independent of the underlying unix
- system. If a byte range lock that the client requests
- happens to fall into the range 0-2^31, Samba hands
- this request down to the Unix system. All other locks
- can not be seen by unix anyway.</para>
-
- <para>Strictly a SMB server should check for locks before
- every read and write call on a file. Unfortunately with the
- way fcntl() works this can be slow and may overstress the
- rpc.lockd. It is also almost always unnecessary as clients
- are supposed to independently make locking calls before reads
- and writes anyway if locking is important to them. By default
- Samba only makes locking calls when explicitly asked
- to by a client, but if you set "strict locking = yes" then it will
- make lock checking calls on every read and write. </para>
-
- <para>You can also disable by range locking completely
- using "locking = no". This is useful for those shares that
- don't support locking or don't need it (such as cdroms). In
- this case Samba fakes the return codes of locking calls to
- tell clients that everything is OK.</para>
-
- <para>The second class of locking is the "deny modes". These
- are set by an application when it opens a file to determine
- what types of access should be allowed simultaneously with
- its open. A client may ask for DENY_NONE, DENY_READ, DENY_WRITE
- or DENY_ALL. There are also special compatibility modes called
- DENY_FCB and DENY_DOS.</para>
-
- <!-- FIXME: Sync this with oplocks.sgml -->
- </sect2>
</sect1>
</chapter>
diff --git a/docs/docbook/projdoc/locking.sgml b/docs/docbook/projdoc/locking.sgml
new file mode 100644
index 0000000000..ef65c16e2c
--- /dev/null
+++ b/docs/docbook/projdoc/locking.sgml
@@ -0,0 +1,60 @@
+<chapter id="locking">
+<chapterinfo>
+ &author.jeremy;
+ &author.jelmer;
+</chapterinfo>
+
+<title>Locking</title>
+
+<para>One area which sometimes causes trouble is locking.</para>
+
+<para>There are two types of locking which need to be
+performed by a SMB server. The first is "record locking"
+which allows a client to lock a range of bytes in a open file.
+The second is the "deny modes" that are specified when a file
+is open.</para>
+
+<para>Record locking semantics under Unix is very
+different from record locking under Windows. Versions
+of Samba before 2.2 have tried to use the native
+fcntl() unix system call to implement proper record
+locking between different Samba clients. This can not
+be fully correct due to several reasons. The simplest
+is the fact that a Windows client is allowed to lock a
+byte range up to 2^32 or 2^64, depending on the client
+OS. The unix locking only supports byte ranges up to
+2^31. So it is not possible to correctly satisfy a
+lock request above 2^31. There are many more
+differences, too many to be listed here.</para>
+
+<para>Samba 2.2 and above implements record locking
+completely independent of the underlying unix
+system. If a byte range lock that the client requests
+happens to fall into the range 0-2^31, Samba hands
+this request down to the Unix system. All other locks
+can not be seen by unix anyway.</para>
+
+<para>Strictly a SMB server should check for locks before
+every read and write call on a file. Unfortunately with the
+way fcntl() works this can be slow and may overstress the
+rpc.lockd. It is also almost always unnecessary as clients
+are supposed to independently make locking calls before reads
+and writes anyway if locking is important to them. By default
+Samba only makes locking calls when explicitly asked
+to by a client, but if you set "strict locking = yes" then it will
+make lock checking calls on every read and write. </para>
+
+<para>You can also disable by range locking completely
+using "locking = no". This is useful for those shares that
+don't support locking or don't need it (such as cdroms). In
+this case Samba fakes the return codes of locking calls to
+tell clients that everything is OK.</para>
+
+<para>The second class of locking is the "deny modes". These
+are set by an application when it opens a file to determine
+what types of access should be allowed simultaneously with
+its open. A client may ask for DENY_NONE, DENY_READ, DENY_WRITE
+or DENY_ALL. There are also special compatibility modes called
+DENY_FCB and DENY_DOS.</para>
+
+</chapter>
diff --git a/docs/docbook/projdoc/samba-doc.sgml b/docs/docbook/projdoc/samba-doc.sgml
index de3c9e2974..a0fc27fcb0 100644
--- a/docs/docbook/projdoc/samba-doc.sgml
+++ b/docs/docbook/projdoc/samba-doc.sgml
@@ -93,6 +93,7 @@ for various environments.
&BROWSING;
&SecuringSamba;
&unicode;
+&locking;
</part>
<part id="troubleshooting">