Improved Microsoft Office compatibility

As has been noted on openafs-info, Microsoft Office applications
tend to be quite fussy about locks.  In speaking with members of
the Microsoft Office team, their applications request an exclusive
lock on a file even when opening it for read-only access in order
to ensure that the file does not change while the file is being
loaded.

One of the questions that needed to be answered when adding lock
support to OpenAFS for Windows was "what does a CIFS exclusive lock
request mean in the context of AFS?"   Our initial approach was to
map shared locks to "read locks" and exclusive locks to "write locks"
but it appears that this approach was a bit too simplistic and
resulted in poor behavior of Microsoft applications when the user
privileges were restricted to "rlk" or "rl".

As of 1.5.15 there will be a change in how locks are enforced.
If a file is opened with only read access, an exclusive lock will
be mapped to a "read lock" instead of a "write lock".  The benefit
of this is that it will provide the assurance that the file will
not change since no write lock can be issued while a read lock is
held while permitting the lock to be issued to those without write
privileges.

If the user does not have any locking privileges at all, the
Windows AFS Cache Manager will fake the lock locally as has been
the existing policy.

Daily builds containing these modifications can be found at:

  /afs/athena.mit.edu/user/j/a/jaltman/Public/OpenAFS\
  \\afs\athena.mit.edu\user\j\a\jaltman\Public\OpenAFS\
  http://web.mit.edu/jaltman/Public/OpenAFS/

Builds labeled 1-5-20070209 or greater contain these changes.
Please report positive and negative results to this list.

Thank you.

Jeffrey Altman