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

comment

Browse source
This commit is contained in:
Joey Hess 2015-07-06 12:24:23 -04:00
parent 32419699bb
commit 9eaec18535
1 changed files with 21 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

21
doc/forum/Robustness_on_failing_hardware/comment_1_d89ffbebe59d05fb2c47d957792cf97e._comment Normal file
View file

@ -0,0 +1,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.
"""]]