Recent comments posted to this site:

There is really no way to do this.

We could consider hard-linking the files, but then modifying one would modify the other, which is likely to be confusing. And, FAT doesn't support hard links anyway.

I don't want to complicate git-annex's notion of whether an object is present or not with the possibility that it might be present for some files but not for others. For example, git annex get would then need to make a copy of content that was already locally present, while currently it knows that if the file is locally present, it has nothing to do.

I think that the solution is to use either a better filesystem which can support the suprerior indirect mode, or to switch your repository to use the WORM backend which does not do deduplication.

Comment by joey Fri Oct 31 20:15:58 2014
An upgrade could move the annexed objects around.
Comment by joey Fri Oct 31 16:55:47 2014

I agree that at least read-only support should be there. This error was from an filesystem type that is impossible to mount read-write.

Now that I am looking at it again with fresh eyes, I suppose it's possible to get around this by mounting an union filesystem with a read-write temp layer on top of the read-only one (not that a regular user would ever figure that out...)

Comment by Jaen Thu Oct 30 19:04:56 2014

I've ran into this as well using wheezy+awesome. It definitely looks like a race condition, I ended up doing a

killall git-annex
git-annex webapp

to get things going again.

Comment by Justin Thu Oct 30 18:07:28 2014

the problem here is that it upgrading the repo will not work on a readonly filesystem, so we can't upgrade, we can't get files, so we can't sync.

we should be able to sync anyways - can't we try our best shot at getting files even without upgrading the metadata? i mean i'm looking for something in .git/annex/objects/, maybe i don't care about tracking so much - i just want to recover some files...

Comment by anarcat Thu Oct 30 15:22:32 2014
yep, that would be fine.
Comment by anarcat Thu Oct 30 15:15:57 2014


thank you for your response. I just want to control my branches (master, dev and so on ...) by myself, without sync/master or sync/dev and without merging it automatically. But the git-annex branch should be populated between the repositories "magically" (some kind of "git annex syncannex"). As annex can't deliver such a basic functionality i assumed, that it was not designed to work with existing "real" git repositories.

Comment by Torkaly Wed Oct 29 18:51:29 2014

The latest version of git-annex adds the ability to git annex info $remote and get all the info you asked for. Enjoy!

Comment by joey Tue Oct 28 20:39:41 2014

If you configure the central repository to be in the "full backup" group, then the assistant and git annex sync --content etc will send the contents of all files to it, and never remove the contents of files from it.

This doesn't prevent someone manually running git annex drop --from $centralrepo --force, or similar. But then, nothing prevents users from using git to push annexed files to the central repo, and never sending the contents of the files along to it.

It would be possible to make git-annex-shell have a config setting that would prevent ever dropping keys. But I'd like to talk about this use case more, to make sure that really makes sense.

Comment by joey Tue Oct 28 20:28:26 2014

git-upload-pack is a git command, which is not present in PATH on your NAS when git sshes in and tries to run it.

Comment by joey Tue Oct 28 20:26:08 2014