Merge branch 'master' of ssh://git-annex.branchable.com

This commit is contained in:
Joey Hess 2012-02-15 11:16:28 -04:00
commit 88b3ee8968
3 changed files with 30 additions and 0 deletions

View file

@ -0,0 +1,10 @@
[[!comment format=mdwn
username="antymat"
ip="77.190.74.127"
subject="comment 2"
date="2012-02-14T22:48:37Z"
content="""
Thanks, joey, but I still do not know, why the file that has been (and *is*) OK according to separate sha1 and sha256 checks, has been marked 'bad' by `fsck` and moved to `.git/annex/bad`. What could be a reason for that? Could have `rsync` caused it? I know too little about internal workings of `git-annex` to answer this question.
But one thing I know for certain - the false positives should *not* happen, unless something *is* wrong with the file. Otherwise, if it is unreliable, if I have to check twice, it is useless. I might as well just keep checksums of all the files and do all checks by hand...
"""]]

View file

@ -0,0 +1,10 @@
[[!comment format=mdwn
username="http://joey.kitenet.net/"
nickname="joey"
subject="comment 3"
date="2012-02-14T22:57:29Z"
content="""
All that git annex fsck does is checksum the file and move it away if the checksum fails.
If bad data was somehow read from the disk that one time, what you describe could occur. I cannot think of any other way it could happen.
"""]]

View file

@ -0,0 +1,10 @@
[[!comment format=mdwn
username="antymat"
ip="77.190.74.127"
subject="comment 4"
date="2012-02-15T07:13:12Z"
content="""
OK, thanks. I was just wondering - since there are links in git(-annex), and a hard links too, that maybe the issue has been caused by `rsync`.
I will keep my eye on that and run checks with my own checksum and `fsck` from time to time, and see what happens. I will post my results here, but the whole run (`fsck` or checksum) takes almost 2 days, so I will not do it too often... ;)
"""]]