diff options
4 files changed, 32 insertions, 1 deletions
diff --git a/Command/Fsck.hs b/Command/Fsck.hs index e8b1d240c..5951a88be 100644 --- a/Command/Fsck.hs +++ b/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 diff --git a/debian/changelog b/debian/changelog index f763ecac2..ed503530b 100644 --- a/debian/changelog +++ b/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 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". +"""]] |