From c0ac957fc2f177f3349b8b763fbd54ade14da56c Mon Sep 17 00:00:00 2001 From: Jelmer Vernooij Date: Mon, 21 Apr 2003 16:16:31 +0000 Subject: Move information about locking to seperate chapter and information about scope id's to the faq (This used to be commit f2c333822f34be8a2bb85124319ead4dc44c2891) --- docs/docbook/projdoc/locking.sgml | 60 +++++++++++++++++++++++++++++++++++++++ 1 file changed, 60 insertions(+) create mode 100644 docs/docbook/projdoc/locking.sgml (limited to 'docs/docbook/projdoc/locking.sgml') 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 @@ + + + &author.jeremy; + &author.jelmer; + + +Locking + +One area which sometimes causes trouble is locking. + +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. + +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. + +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. + +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. + +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. + +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. + + -- cgit