From: Joey Hess <joeyh@joeyh.name>
Date: Mon, 26 Jul 2021 18:12:58 +0000 (-0400)
Subject: fix a place where the inode cache could potentially have gotten stale
X-Git-Tag: archive/raspbian/10.20250416-2+rpi1~2^2^2~69^2~33
X-Git-Url: https://dgit.raspbian.org/?a=commitdiff_plain;h=46375923256cd06f8e2512e43a710b57e34dcba3;p=git-annex.git

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 3d085393a8..620da40133 100644
--- 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