SAMBA & ISAM Databases

Richard Sharpe rsharpe at
Wed Sep 15 17:21:55 GMT 2004

On Wed, 15 Sep 2004, Christopher R. Hertel wrote:

> Okay, so...
> Based on the info Andrew provided and some of the other comments in this
> thread, it seems that the problem is:
> - Linux/Posix supports locking semantics that are different from those
>   used by Windows.
>   I knew, generally, this was a problem but I wasn't quite sure how much
>   of a problem it was.  Seems to be bigger than I thought.  The issue here
>   is two-fold.  First, the Linux client needs to translate locking
>   semantics to match the needs of CIFS.  Next, the Samba server needs to
>   translate to Posix semantics for all clients.  Ouch.
> - The core of the problem is that the database is being accessed as a
>   shared file, so each client must be able to read and write it
>   simultaneously--thus the importance of locking.

Hmmm, there are several issues here, I think.

Firstly, was the file being accessed from UNIX and attempting to use fcntl
or etc advisory locking? Also, were these being mapped to CIFS byte-range
locks via smbfs/cifsvfs?

Secondly, it seems that there is need for a standard around the correct
interaction between CIFS and UNIX locks.

Steve French and I discussed this briefly at CIFS2004 but we have not
taken it much further.

I do think that it will be worth writing an RFC on this topic. There has
been some work by HP, but I do not think it addresses all the issues.

The issues that must be addressed include how do CIFS byte-range and
share-mode locks interact with UNIX advisory locks and UNIX/NFS read and
write operations as well as how do UNIX advisory locks interact with CIFS
byte-range and share-mode locks as well as read and write operations etc.

A helpful way to look at this, ISTM, is to separate locking out from IO

The spec should also point out those areas in which you can lose. Ie, if a
Windows user has a lock on a file, and a UNIX app does not bother to use
advisory locking before accessing the file, you can lose.

Richard Sharpe, rsharpe[at], rsharpe[at],

More information about the samba-technical mailing list