POSIX client locking semantics.

[Jeremy Allison]

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

Thoughts and comments welcome !

Jeremy.