From 46375923256cd06f8e2512e43a710b57e34dcba3 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Mon, 26 Jul 2021 14:12:58 -0400 Subject: [PATCH] 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. --- Command/Lock.hs | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) 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 -- 2.30.2