mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages 1 Wiki Activity Actions

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

Browse source
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
Download patch file Download diff file Expand all files Collapse all files

1
doc/bugs/fsck_of_special_remotes_incorrectly_reports_ok.mdwn
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]]

26
doc/bugs/fsck_of_special_remotes_incorrectly_reports_ok/comment_1_b76598aebcaccf1e1065dc6372a333ab._comment Normal file
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".
"""]]