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

2 files changed, 27 insertions, 0 deletions

diff --git a/doc/bugs/fsck_of_special_remotes_incorrectly_reports_ok.mdwn b/doc/bugs/fsck_of_special_remotes_incorrectly_reports_ok.mdwn
index 809725127..fb0f84150 100644
--- a/doc/bugs/fsck_of_special_remotes_incorrectly_reports_ok.mdwn
+++ b/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]]
diff --git a/doc/bugs/fsck_of_special_remotes_incorrectly_reports_ok/comment_1_b76598aebcaccf1e1065dc6372a333ab._comment b/doc/bugs/fsck_of_special_remotes_incorrectly_reports_ok/comment_1_b76598aebcaccf1e1065dc6372a333ab._comment
new file mode 100644
index 000000000..52f42ba89
--- /dev/null
+++ b/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".
+"""]]