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

This commit is contained in:
Joey Hess 2015-02-10 13:10:58 -04:00
parent 00e75c7a2a
commit 4794ef083a
4 changed files with 32 additions and 1 deletions

View file

@ -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

1
debian/changelog vendored
View file

@ -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

View file

@ -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]]

View file

@ -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".
"""]]