fsck --from: If a download from a remote fails, propigate the failure.
This commit is contained in:
parent
00e75c7a2a
commit
4794ef083a
4 changed files with 32 additions and 1 deletions
|
@ -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
1
debian/changelog
vendored
|
@ -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
|
||||
|
||||
|
|
|
@ -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]]
|
||||
|
|
|
@ -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".
|
||||
"""]]
|
Loading…
Add table
Add a link
Reference in a new issue