fsck: When a key is not previously known in the location log, record something so that reinject --known will work.

Command/Fsck.hs

@@ -258,7 +258,14 @@ verifyLocationLog' key desc present u updatestatus = do
 				++ "\n** was expected to be present, " ++
 				"but its content is missing."
 			return False
-		_ -> return True
+		(False, False) -> do
+			-- When the location log for the key is not present,
+			-- create it, so that the key will be known.
+			when (null uuids) $
+				whenM (not <$> isKnownKey key) $
+					updatestatus InfoMissing
+			return True
+		(True, True) -> return True
   where
 	fix s = do
 		showNote "fixing location log"

debian/changelog

@@ -23,6 +23,8 @@ git-annex (6.20160420) UNRELEASED; urgency=medium
   * Added annex.gnupg-decrypt-options and
     remote.<name>.annex-gnupg-decrypt-options, which are passed to gpg
     when it's decrypting data.
+  * fsck: When a key is not previously known in the location log,
+    record something so that reinject --known will work.
 
  -- Joey Hess <id@joeyh.name>  Thu, 28 Apr 2016 13:17:04 -0400
 

doc/forum/Making_a_git-annexy_symlink___34__known__34____63__/comment_1_e04edbe950a41887c4c11a226ca77dce._comment

@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-05-10T17:04:20Z"
+ content="""
+fsck sees that the (lack of) location
+log accurately states that the content is not present, and so avoids
+writing to the log.
+
+If fsck always wrote to the log when content was not present, running
+fsck in sparse repos would bloat the location logs unncessarily.
+
+But I suppose that it makes sense for fsck to notice that the key
+was not known and write to the log in this particular case.
+I've gone ahead and made that change.
+
+It's not clear to me though, why this workflow of copying over symlinks,
+and adding them and reinjecting is better than just moving over content and
+adding it.
+"""]]