Comments in the moderation queue:
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
git annex get
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.
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...)
I've ran into this as well using wheezy+awesome. It definitely looks like a race condition, I ended up doing a
to get things going again.
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...
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.
The latest version of git-annex adds the ability to git annex info
$remote and get all the info you asked for. Enjoy!
git annex info
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
git annex sync --content
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.
git annex drop --from
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.
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.