use InodeCache when dropping a key to see if a pointer file can be safely reset

The Keys database can hold multiple inode caches for a given key. One for
the annex object, and one for each pointer file, which may not be hard
linked to it.

Inode caches for a key are recorded when its content is added to the annex,
but only if it has known pointer files. This is to avoid the overhead of
maintaining the database when not needed.

When the smudge filter outputs a file's content, the inode cache is not
updated, because git's smudge interface doesn't let us write the file. So,
dropping will fall back to doing an expensive verification then. Ideally,
git's interface would be improved, and then the inode cache could be
updated then too.

1 files changed, 15 insertions, 7 deletions

diff --git a/Annex/Content.hs b/Annex/Content.hs
index a530245b3..e635b97a3 100644
--- a/Annex/Content.hs
+++ b/Annex/Content.hs
@@ -451,7 +451,9 @@ moveAnnex key src = withObjectLoc key storeobject storedirect
 			fs <- Database.Keys.getAssociatedFiles key
 			if null fs
 				then freezeContent dest
-				else mapM_ (populatePointerFile key dest) fs
+				else do
+					mapM_ (populatePointerFile key dest) fs
+					Database.Keys.storeInodeCaches key (dest:fs)
 		)
 	storeindirect = storeobject =<< calcRepo (gitAnnexLocation key)
 
@@ -505,7 +507,9 @@ linkAnnex key src = do
 		( return LinkAnnexNoop
 		, modifyContent dest $
 			ifM (liftIO $ createLinkOrCopy src dest)
-				( return LinkAnnexOk
+				( do
+					Database.Keys.storeInodeCaches key [dest, src]
+					return LinkAnnexOk
 				, return LinkAnnexFailed
 				)
 		)
@@ -601,6 +605,7 @@ removeAnnex (ContentRemovalLock key) = withObjectLoc key remove removedirect
 		removeInodeCache key
 		mapM_ (void . tryIO . resetPointerFile key)
 			=<< Database.Keys.getAssociatedFiles key
+		Database.Keys.removeInodeCaches key
 	removedirect fs = do
 		cache <- recordedInodeCache key
 		removeInodeCache key
@@ -613,8 +618,7 @@ removeAnnex (ContentRemovalLock key) = withObjectLoc key remove removedirect
 {- To safely reset a pointer file, it has to be the unmodified content of
  - the key. The expensive way to tell is to do a verification of its content.
  - The cheaper way is to see if the InodeCache for the key matches the
- - file.
- -}
+ - file. -}
 resetPointerFile :: Key -> FilePath -> Annex ()
 resetPointerFile key f = go =<< geti
   where
@@ -624,10 +628,14 @@ resetPointerFile key f = go =<< geti
 			secureErase f
 			liftIO $ nukeFile f
 			liftIO $ writeFile f (formatPointer key)
-		, noop
+		-- Can't delete the pointer file.
+		-- If it was a hard link to the annex object,
+		-- that object might have been frozen as part of the
+		-- removal process, so thaw it.
+		, thawContent f
 		)
-	cheapcheck fc = maybe (return False) (compareInodeCaches fc)
-		=<< Database.Keys.getInodeCache key
+	cheapcheck fc = anyM (compareInodeCaches fc)
+		=<< Database.Keys.getInodeCaches key
 	expensivecheck fc = ifM (verifyKeyContent AlwaysVerify Types.Remote.UnVerified key f)
 		-- The file could have been modified while it was
 		-- being verified. Detect that.