fsck --from: If a download from a remote fails, propigate the failure.

Command/Fsck.hs

@@ -141,7 +141,10 @@ performRemote key file backend numcopies remote =
 	dispatch (Right True) = withtmp $ \tmpfile ->
 		ifM (getfile tmpfile)
 			( go True (Just tmpfile)
-			, go True Nothing
+			, do
+				warning "failed to download file from remote"
+				go True Nothing
+				return False
 			)
 	dispatch (Right False) = go False Nothing
 	go present localcopy = check

debian/changelog

@@ -21,6 +21,7 @@ git-annex (5.20150206) UNRELEASED; urgency=medium
   * addurl: Avoid crash if quvi is not installed, when git-annex was
     built with process-1.2
   * bittorrent: Fix mojibake introduced in parsing arai2c progress output.
+  * fsck --from: If a download from a remote fails, propigate the failure.
 
  -- Joey Hess <id@joeyh.name>  Fri, 06 Feb 2015 13:57:08 -0400
 

doc/bugs/fsck_of_special_remotes_incorrectly_reports_ok.mdwn

@@ -33,3 +33,4 @@ Not really sure, but rerunning the commands show that the openBinaryFile happens
 
 built using Homebrew (i.e. in a cabal sandbox) on OS X Yosemite 10.10.1
 
+> [[fixed|done]] as described in comment --[[Joey]]

doc/bugs/fsck_of_special_remotes_incorrectly_reports_ok/comment_1_b76598aebcaccf1e1065dc6372a333ab._comment

@@ -0,0 +1,26 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-02-10T17:04:10Z"
+ content="""
+So, what's going on here is:
+
+* fsck first calls hasKey to check if the remote has the key
+* It does, so it proceeds to try to download the file
+* This fails for whatever reason (probably a transient network error
+  in the first example, and a bug in your code in the second)
+* So, fsck bypasses checking the checksum, and just assumes that
+  hasKey was right, the key is present in the remote.
+
+Question is, should it instead assume hasKey is innaccurate,
+and mark the remote as no longer containing the file jut because
+it failed to download it once?
+
+I don't think so. This would mean that fsck --from networkremote
+and then dropping network connection in the middle of the file
+download would mark the file as not present on the remote any longer.
+
+I think though, that it would make sense for fsck to propigate an
+error in this case. It can leave the location log as-is, but not
+assume "ok".
+"""]]