POSIX client locking semantics.

[conrad at mac.com]

At 3:27 PM -0700 10/19/05, Jeremy Allison wrote:
>[This time sent with the right subject line, sorry. Jeremy]
>
>Ok, I've started to think about the semantics of CIFS POSIX
>locks within Samba, and there are some interesting challenges.
>
>We're currently thinking of a "posix get/set" lock trans2
>UNIX smb call - so far so good (easy). It's obvious that
>POSIX locks conflict at set time, but what I'm trying to
>work out is how these should interact with Windows read/write
>calls and Windows mandatory locks.
>
>The easiest thing to do is to map CIFS posix locks onto a
>kind of Windows lock, with the added ability to split/merge
>lock ranges, and to upgrade/downgrade lock types (as POSIX
>allows).
>
>That way the Windows locks will automatically conflict,
>which is what you want. You'd like a POSIX lock set by
>a UNIX client to conflict with Windows locks - and vica
>versa. You'd also like a read or write from a Windows
>client to conflict with both POSIX and Windows locks
>(as they do now). The interesting case is a read or
>write from a UNIX client.
>
>You'd like these to conflict with Windows locks, as
>that's current behaviour, but not to conflict with
>POSIX locks, as that is POSIX behaviour. The problem
>is the server needs to know if a read/write is a POSIX-style
>read/write or a Windows one.
>
>I'm proposing that we use the same mechanism we used to
>select case-sensitive pathname traversal for POSIX clients,
>in that a POSIX client does a setfsinfo with a capability
>of CIFS_UNIX_POSIX_READWRITE_CAP (this can be OR'ed in
>to the same setfsinfo that selects the case sensitive
>filenames) - once this is set then read/writes on this
>tid will be done with POSIX semantics - eg. POSIX locks
>will be ignored. Yes it's horrible, but no worse than
>the case-sensitive select.

Sounds good.

If POSIX clients need to request special behavior like that, then do you still need a distinct posix get/set lock trans2?  A  CIFS_UNIX_POSIX_CAP could enable POSIX behavior (including the fcntl F_GETLK capability not present in smb otw.)