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
operations.

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.

Regards
-----
Richard Sharpe, rsharpe[at]richardsharpe.com, rsharpe[at]samba.org,
sharpe[at]ethereal.com, http://www.richardsharpe.com