summaryrefslogtreecommitdiff
path: root/doc/bugs/fsck_of_special_remotes_incorrectly_reports_ok/comment_1_b76598aebcaccf1e1065dc6372a333ab._comment
blob: 52f42ba89145b1d64e5234a13225a4c2e9bccced (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
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".
"""]]