byte range locks and evolution

[Steven French]

Although emulating posix advisory locks by use of mandatory cifs locks
works in many cases, there are cases that we have found that this does not
work.

When jra has finished adding the code for Samba to handle the SMB trans2
unix set_fs_info which specifies that the cifs client wants posix byte
range lock semantics (currently only two of the other flags are supported
in Samba server for posix acls and posix pathnames) this will work to
samba, but for everyone else there has to be a way around this.   There are
two choices
      - mapping advisory to mandatory byte range locks (current behavior)
      - disabling sending byte range locks remotely (perhaps an
optimization is to not send byte range locks when the file is oplocked)
I suspect that the best way to handle this is via a mount option, but what
should be the default? and what should be its name?

The evolution email application unfortunately makes it pretty much required
that we change cifs vfs since it does byte range locks on the wrong
filehandle (and opens a file twice that it only needed to open once ...).
We can't even do the oplock optimization (don't send byte range locks on
oplocked files) since evolution opens the outbox file with different modes
(one read/write and one write) which causes a self oplock break (I wonder
if we could avoid doing self oplock breaks ... by telling the server this
is ok).


Steve French
Senior Software Engineer
Linux Technology Center - IBM Austin
phone: 512-838-2294
email: sfrench at-sign us dot ibm dot com