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

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

Browse source
This commit is contained in:
Joey Hess 2013-01-14 14:31:07 -04:00
commit 78c7efb258
3 changed files with 59 additions and 1 deletions
Download patch file Download diff file Expand all files Collapse all files

25
doc/bugs/fsck_should_double-check_when_a_content-check_fails/comment_2_41214a7d18c66b694645248d6ebeadbf._comment Normal file
View file

@ -0,0 +1,25 @@
[[!comment format=mdwn
username="https://www.google.com/accounts/o8/id?id=AItOawkHDm_DOFRcHYebCnnYKKyIwiPD4iOiiIU"
nickname="Jörn"
subject="comment 2"
date="2013-01-14T17:37:45Z"
content="""
Maybe I was too quick in blaming the hard drive. It might be my problem is somewhere else. Let me do what I should have done in the first place and give you a detailed problem description:
I have got three hard drives, two internal, one external connected via USB. I have got a couple of repositories with small files (mp3, JPEGs and so on). Those are fine, fsck never complains about them.
But in one repository with video files (i.e. much bigger files than in the other repos), git-annex fsck will always find some broken files. I run git-annex get to retrieve the broken files from other sources. Then I run
fsck again - and it complains about some other files. This happens on all drives.
This could mean:
- all my drives are broken. However, SMART data are unsuspicious, and one of the drives is just a couple of days old.
- git-annex fsck is broken
- read errors like I mentioned in my first post
- some process actually _altering_ the files (should not happen when the files are locked, right?)
- something completely different? Some possibly dangerous source of radiation? :)
Any ideas on this? Maybe I should hash the data in .git/annex/bad and check which value I get - can I tell git-annex to do so?
Thanks,
Jörn
"""]]

33
doc/bugs/three_way_sync_via_S3_and_Jabber/comment_3_063f5e5e554ad6710f16394906d87616._comment Normal file
View file

@ -0,0 +1,33 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="4.154.7.238"
subject="comment 3"
date="2013-01-14T17:40:51Z"
content="""
`git annex sync` cannot sync xmpp remotes. Only the assistant can do that. So that's a red herring indeed..
I've replicated the same setup with 3 repositories all paired using a single jabber account.
In my test, all 3 stay in sync, with any change to one git repository being synced to the other 2.
I checked the XMPP sync protocol, and it doesn't use the UUIDs at all for XMPP syncing, so the fact that `.git/config` only has the UUID of one of the two repositories that is accessible via XMPP in this case, should not matter. That is, though, why the webapp only shows one of the other two repositories; it's using that UUID information.
Dagon seems to be where the problem is occuring; it's not managing to sync out its changes via XMPP.
I think the thing to do is create another new file on dagon, and look at its `.git/annex/daemon.log`.
You should see two xmpp pushes happen, which would look rather like this:
<pre>
To xmpp::you@gmail.com
a7549be..011ccc2 git-annex -> refs/synced/9346f5a8-5e63-11e2-bd8b-77356d7f5bd0/git-annex
3acca89..5123067 master -> refs/synced/9346f5a8-5e63-11e2-bd8b-77356d7f5bd0/master
Counting objects: 12, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (6/6), done.
Writing objects: 100% (7/7), 622 bytes, done.
Total 7 (delta 3), reused 0 (delta 0)
To xmpp::you@gmail.com
a7549be..011ccc2 git-annex -> refs/synced/9346f5a8-5e63-11e2-bd8b-77356d7f5bd0/git-annex
3acca89..5123067 master -> refs/synced/9346f5a8-5e63-11e2-bd8b-77356d7f5bd0/master
</pre>
If you don't see both pushes, maybe you'll see a useful error message.
"""]]