1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
|
[[!comment format=mdwn
username="joey"
subject="""comment 1"""
date="2015-07-06T16:09:22Z"
content="""
If the remote that git-annex is moving files to uses rsync as its transport
(ie, is a regular git remote, or a rsync special remote), then
the receiving rsync process verifies a checksum of the file it's receiving.
So, if the sender sends incorrect data, or calculates the wrong checksum
for the right data, the rsync will fail, and git-annex won't delete the
local copy of the file. I guess that if the sending rsync reads bad data
from disk, these checksums won't prevent the bad data being sent to the
remote though. (Some other special remotes don't have a transfer checksum
at all.)
If I had hardware this broken, I'd be glad that `git annex fsck` detected
it, and would move the storage to good hardware and run my fsck there to
learn the actual state of my repository. Re-running checksums or using
multiple checksum types to work around badly broken hardware seems like a
losing idea to me.
"""]]
|
