(datalad-0.13) nastase@head2:/backup/tmp/sam-study-1021/containers/licenses$ git annex metadata freesurfer -s distribution-restrictions=sensitive
metadata freesurfer
distribution-restrictions=sensitive
distribution-restrictions-lastchanged=2020-06-26@14-15-10
lastchanged=2020-06-26@14-15-10
ok
(recording state in git...)
error: invalid object 100644 13a548163abc38cac81810399bcf5a8792c56763 for 'group.log'
fatal: git-write-tree: error building trees
git-annex: failed to read sha from git write-tree
CallStack (from HasCallStack):
error, called at ./Git/Sha.hs:23:15 in main:Git.Sha
(datalad-0.13) nastase@head2:/backup/tmp/sam-study-1021/containers/licenses$ git annex version | head -n 1
git-annex version: 8.20200617-g02765b8
I think nothing odd was done besides trying to make this file saved unlocked for a while with datalad
install --reckless=ephemeral
where we symlink.git/annex
Apparently .git/annex/index refers to a blob that is not in the git repository.
I don't see a git-annex bug here.
Making a shared clone rather than symlinking .git/annex would avoid this situation.
This certianly looks like a file handle leak in git-annex filter-process..
A workaround for you would be to run:
I have tried to reproduce this. I made a repository with 10000 files, all annexed and unlocked. I upgraded it to repository version 9. I checked out a commit where all the files were not present yet, and then checked out a commit that had all the files present. It did not fail, and also I never saw it having more than a few files open.
So there must be something else about your repository that is needed to reproduce this..
(Weirdly, signal 15 is SIGTERM, so I don't know what would have caused it to receive that signal unless it was ctrl-c'd.)