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
This commit is contained in:
Joey Hess 2022-01-13 13:28:57 -04:00
parent 731b1ecf87
commit 3d7933f124
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38

View file

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