[3/3] server: Try to get a read lock if we can't get a write lock.

[Vincent Povirk]

Since the storage code uses only exclusive locks, and exclusive locks
on files opened for reading don't really work, it means we can't
really enforce the sharing modes when someone opens a file for
reading. (I'm thinking of the case of multiple users accessing a file
over a network. If both accesses happen in the same wine prefix, the
server takes care of it.) This is especially a problem for things like
priority mode where they need to prevent commits from happening.

In most cases, falling back on a read lock would solve this. As long
as at least one party has the file open in write mode, their locks
will conflict with the others', and the locking code will still work.
It's incomplete, but I think it's better than nothing.
-------------- next part --------------
From 83a7637bb5202711e5fe715608c74df684d4b33f Mon Sep 17 00:00:00 2001
From: Vincent Povirk <vincent at codeweavers.com>
Date: Thu, 8 May 2014 15:03:10 -0500
Subject: [PATCH 3/3] server: Try to get a read lock if we can't get a write
 lock.

---
 server/fd.c | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/server/fd.c b/server/fd.c
index fa8874c..7043d04 100644
--- a/server/fd.c
+++ b/server/fd.c
@@ -1175,8 +1175,12 @@ static int set_unix_lock( struct fd *fd, file_pos_t start, file_pos_t end, int t
             return 0;
         case EBADF:
             /* this can happen if we try to set a write lock on a read-only file */
-            /* we just ignore that error */
-            if (fl.l_type == F_WRLCK) return 1;
+            /* try to at least grab a read lock */
+            if (fl.l_type == F_WRLCK)
+            {
+                type = F_RDLCK;
+                break; /* retry */
+            }
             set_error( STATUS_ACCESS_DENIED );
             return 0;
 #ifdef EOVERFLOW
-- 
1.8.3.2