fix inverted logic

Now the content lock files are used in v9. However, I am not yet certian
they are correct. In particular, lockContentUsing deletes
the content lock file on unlock. But what if there's a shared lock
by another process? That seems like it would discard that lock too!

(Windows seems like it would not have the same problem, because as the
comment in there says, "Can't delete a locked file on Windows".
So if another process has a shared lock, removing it presumably fails.)

Sponsored-by: Dartmouth College's Datalad project

diff --git a/Annex/Content/Presence.hs b/Annex/Content/Presence.hs
index df57716220e63c30674a52f6a19b24d68d328633..091da5398512310096e5f94aa616d47930d8c950 100644 (file)
--- a/Annex/Content/Presence.hs
+++ b/Annex/Content/Presence.hs
@@ -122,8 +122,8 @@ contentLockFile :: Key -> Annex (Maybe RawFilePath)
  - versions use a separate lock file, to better support repos shared
  - amoung users in eg a group. -}
 contentLockFile key = ifM (versionNeedsWritableContentFiles <$> getVersion)
-       ( pure Nothing
-       , Just <$> calcRepo (gitAnnexContentLock key)
+       ( Just <$> calcRepo (gitAnnexContentLock key)
+       , pure Nothing
        )
 #else
 {- Windows always has to use a separate lock file from the content, since