Fix bug preventing moving files to/from a repository with annex.pidlock set.

Utility/LockPool/PidLock.hs

@@ -33,7 +33,7 @@ import Prelude
 -- Takes a pid lock, blocking until the lock is available or the timeout.
 waitLock :: Seconds -> LockFile -> IO LockHandle
 waitLock timeout file = makeLockHandle
-	(P.waitTakeLock P.lockPool file LockExclusive)
+	(P.waitTakeLock P.lockPool file LockShared)
 	(mk <$> F.waitLock timeout file)
 
 -- Tries to take a pid lock, but does not block.

debian/changelog

@@ -2,6 +2,7 @@ git-annex (6.20160230) UNRELEASED; urgency=medium
 
   * metadata: Added -r to remove all current values of a field.
   * Fix data loss that can occur when annex.pidlock is set in a repository.
+  * Fix bug preventing moving files to/from a repository with annex.pidlock set.
 
  -- Joey Hess <id@joeyh.name>  Mon, 29 Feb 2016 13:00:30 -0400
 

doc/bugs/thread_blocked_indefinitely_in_an_STM_transaction__while_moving_within__a_local_clone.mdwn

@@ -37,3 +37,4 @@ and it works ok without pidlock enabled
 
 [[!meta author=yoh]]
 
+> [[fixed|done]] --[[Joey]]

doc/bugs/thread_blocked_indefinitely_in_an_STM_transaction__while_moving_within__a_local_clone/comment_3_7e6b3ab0beaca49d7d68c9e610c1d147._comment

@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2016-03-01T16:21:31Z"
+ content="""
+Analysis: What's crashing is Utility.LockPool.PidLock.waitLock after a call
+to Utility.LockPool.PidLock.tryLock. The former takes an exclusive STM lock
+of the pid lock file; the latter takes a shared STM lock. 
+
+Since the pid lock stands in for multiple more fine-grained locks, waitLock
+will be called while a lock from tryLock (or a previous waitLock perhaps)
+is still open.
+
+The fix seems as simple as making waitLock take a shared STM lock of the
+pid lock file, leaving the exclusive lock for the later, more fine-grained
+STM lock checking that's done after taking the pid lock.
+"""]]