What version of git-annex are you using? On what operating system?
6.20171001+gitg542d0649f-1~ndall+1
What steps will reproduce the problem?
$> git annex info
git-annex: .git/annex/misctmp/mergedrefs.0: createDirectory: permission denied (Permission denied)
failed
git-annex: info: 1 failed
unless there is really a need to have this operations performed within the same repository/the same filesystem, I do not understand why generic $TMPDIR could not be used for such operations so no write access has to be demanded
done; I implemented annex.merge-annex-branches=false to avoid the unwanted behavior, and have not heard any complaints, so.. --Joey
The mergedrefs directory is used while building the commit to merge git-annex branches. So even if it was written someplace else, that commit would fail.
I think this may be happening even when there are no git-annex refs to merge in, due to the transition code in Annex.Branch.updateTo that temporarily calls addMergedRefs in the "null tomerge" case. That was added in 2016, and is flagged as able to be safely removed. I've removed it.
However, when there actually is a git-annex branch to merge, if a hypothetical readonly mode avoided doing so, it would necessarily see a different state of the git-annex branch than would be seen in non-readonly mode. That behavior difference could be fairly confusing potentially..
--read-onlyflag to such commands asinfoandwhereis. Then we (datalad) would be the one to explicitly check if there is write-permissions and if not -- issue the command in--read-onlymode. We might even make it a default mode of operation for some of our usecases where it would be confusing if things were changing in the background (e.g. withlscommand)There are situations where a git command that appears to be read-only, such as
git statusactually writes to the repository behind the scenes. It looks like git ignores write errors in at least some such cases. So there is precident for implicit read-only support, but I think not in cases where it would involve significant behavior changes, like it would for the git-annex branch auto-merging. In git's case the behavior change probably only involves repeatedgit statusruns being slower than otherwise, or something like that.As well as populating the .git/annex/index file with information merged in from recently fetched git-annex branches, git-annex may need to write to other files in order to prepare caches needed to perform what appears to be "read-only" query operation, or to lock files in order to prevent someone who does have write access from dropping them in a situation where that will lose data. An example of the latter is running
git annex dropin a repository you do have write access to, and it needing to exclusively lock files in origin, which requires write access to origin as well. Without write access, the drop may fail.The --read-only flag seems to be setting up a situation where git-annex handles some things being read-only, but then someone expects the flag to make some other thing work read-only, which git-annex can't manage to support for whatever reason.
So I prefer a more specific name, like annex.merge-annex-branches=false.
Implemented that.