fix a place where the inode cache could potentially have gotten stale

When git-annex lock repopulates the object file by copying an associated
file that still has its content, it negected to update the inode cache.

I was not able to actually get this code to successfully repopulate the
object file; the associated file gets replaced with a dangling pointer
before unlock is able to do that. (By what I'm not sure..
reconcileStaged?) Which might be itself a bug, but
anyway this makes me doubtful that this was really leading to a stale
inode cache. Still, in case there is some situation in which it does
work, fixed it to update the inode cache.

diff --git a/Command/Lock.hs b/Command/Lock.hs
index 3d085393a8e1bd7722975b972d9f64de1371ee2f..620da4013350d1602fe7762c83ee8862cff1cf15 100644 (file)
--- a/Command/Lock.hs
+++ b/Command/Lock.hs
@@ -91,8 +91,10 @@ perform file key = do
                liftIO $ removeWhenExistsWith R.removeLink obj
                case mfile of
                        Just unmodified ->
-                               unlessM (checkedCopyFile key unmodified obj Nothing)
-                                       lostcontent
+                               ifM (checkedCopyFile key unmodified obj Nothing)
+                                       ( Database.Keys.storeInodeCaches key [obj]
+                                       , lostcontent
+                                       )
                        Nothing -> lostcontent
 
        lostcontent = logStatus key InfoMissing