Recent comments posted to this site:

I see now that git-annex only reports the ipfs hash when the remote is unencrypted. It the ipfs hash not reported for encrypted ipfs remotes for security reasons?
Comment by rob.syme Tue May 26 05:08:38 2015

I'm using git-annex version: 5.20150522-gb199d65

The example above gives the ipfs hash for the file, but when I run whereis, the hash is not reported:

$ git annex whereis test.txt
whereis test.txt (2 copies) 
        1bd0f840-2247-4888-9237-596515788671 -- rob@rob-G60JX:/tmp/gitannextest [here]
        adf361b3-7b1a-43e1-8360-937f7e436e90 -- [ipfs]

Is there a way for git-annex to report the file's ipfs hash ID?

Comment by rob.syme Tue May 26 04:55:32 2015

Hm, not so sure that "rebooted, did not help" was actually true. I take that back.

Now I saw a stray git-annex-shell recv-key process mentioning that file. I killed it and now everything seems fine. I will keep this in mind for next time, to see if I can verify that this was actually the cause of the message, but maybe it's a clue.

Comment by clacke Sun May 24 17:41:17 2015
I suppose since an I/O error can be intermittent, the file can’t be outright regarded as bad. Also I’m not sure whether the read system call returns a dedicated error code for checksum errors.
Comment by eigengrau Sun May 24 15:07:34 2015
Thanks! This would be useful. While it probably takes up only little disk space, the noise it creates during fsck would make it harder to discern which data has been unintentionally lost, as opposed to migrated to another back-end.
Comment by eigengrau Sun May 24 14:58:30 2015


I would like to uses git-annex in combination with Tahoe-LAFS. The grid will consist of private Servers connected though slow DSL-Lines. Thus I would like to use the Tahoe-LAFS helper feature (like a Tahoe-LAFS upload proxy):

This will result in a different FURL for each location pointing to the same Tahoe-LAFS grid.

How can I setup two git-annex clients to use two different FURLs for the same remote (the same Tahoe-LAFS grid)?

Thank you very much for your help!


Comment by junk Sun May 24 13:48:33 2015
Note that a thousand files went over without a hitch, but this particular file consistently fails.
Comment by clacke Fri May 22 22:16:45 2015

It's weirder than that. I add a cow union mount over it, it works fine.

I copy the file, I drop the file, I remove the union mount. Again it's back in the broken state. Rebooting does not help, so it's not some very insistent lock.

Next I will try a copy of the repo, to see if that is able to carry over whatever strange state this thing is in.

Comment by clacke Fri May 22 21:08:26 2015

I think I've seen this where the shell was running some command at (non-interactive) login that output stuff and so screwed up the rsync protocol.

rsync with sufficient -vvvv will print out a lot of debugging info about the protocol.

Comment by joey Fri May 22 19:12:37 2015

Aha, this is a path propel to the trustedkeys.gpg file, it's in bundle/ in the OSX app, and git-annex tells gpg to look in the parent directory instead.

Fixed in git. Unfortunately I can't fix old versions of git-annex so OSX users will need to manually upgrade to version 5.20150522 to get this fix.

Comment by joey Fri May 22 17:35:11 2015