Please describe the problem.
git-annex failed to update the local adjusted branch after git annex drop stopped abruptly. In turn, git annex drop stopped abruptly because a git annex copy --from X --to Y had to be stopped (CTRL-C) because of lack of space.
(Perhaps there are two issues here: drop being unable to cope with the unexpected situation, and the adjustment code being unable to cope with the weird stat left by drop's abrupt interruption.)
What steps will reproduce the problem?
$ git copy -J4 --from X --to Y
[notice that git-annex starts saying "not enough free space, need 27.87 MB more"]
[kill process with CTRL-C]
$ git annex drop dirF/
drop dirF/a/a1.txt ok
drop dirF/a/a2.txt ok
[...]
error: Your local changes to the following files would be overwritten by checkout:
dirF/a/a1.txt
dirF/a/a2.txt
[...]
Aborting
Updating adjusted branch failed.
(recording state in git...)
$ git status
HEAD detached at 9d92415fb
nothing to commit, working tree clean
$ git annex status
$ git branch
* (HEAD detached at 9d92415fb)
adjusted/master(unlocked)
adjusted/master(unlockpresent)
git-annex
master
synced/master
dirF/ is the directory whose files were being copied when the process has been stopped with CTRL-C.
What version of git-annex are you using? On what operating system?
git-annex version: 10.20230215-gd24914f2a
[...]
operating system: linux x86_64
supported repository versions: 8 9 10
upgrade supported from repository versions: 0 1 2 3 4 5 6 7 8 9 10
local repository version: 8
Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
git-annex is too good. It so rarely causes problems that one does not develop the "git-annex troubleshooting muscle". 
I assume this is a --hide-missing adjusted branch?
Update: Oh, I see from a forum post that it's --unlock-present actually.
What is the annex.adjustedbranchrefresh git config set to?
I was able to reproduce something that looks similar to this without needing to interrupt any command:
And it was left in a similar detached head status:
This seems be be a bug with the implementation of annex.adjustedbranchrefresh
git-annex is what writes that detached HEAD, in updateAdjustedBranch. And I've verified that when it fails like this, git status shows the file is modified. But of course the modification is only that the annex content has been replaced by an annex pointer. Running
git addon the file makes the modification status go away.And this only happens when annex.adjustedbranchrefresh=1. At higher values, it calls Annex.Queue.flush, but at 1 it does not, and so restagePointerFiles does not get called before adjustedBranchRefreshFull. (Or at least may not, they're both running as cleanup actions and order is not really defined.)
I wonder if there are other situations where modifications can prevent checkout of the updated adjusted branch? Eg, what if the user has made some other modification to an annexed file? It seems wise for git-annex to defend against it in depth, by making sure no crash can leave it in detached head state.
Thanks for investigating this!
These are the local settings:
I clearly remember seeing something similar when a
syncfailed due a non-recoverable network failure. Unfortunately I have no logs from that day.Perhaps also extend
fsckto automatically recover from such a state? Or at least suggest a couple of possible solutions to the user?Weird, I don't see how a network failure could lead in that direction.
Anyway, 038a2600f4cf71294976280c5c29f6710359375f avoids it with a detached head.
git-annex fsck can't do anything about this because the user may have their own reasons to check out a detached head.
All I remember is that the command that was running was
git annex sync --content.Perhaps the fact that
annex.alwayscommit = falsewas set made a difference.With git-annex 10.20230329-g30d7f9ad7 I got the following message after checking out
adjusted/master(unlockpresent)and runninggit annex copy --from foo --to bar -J2:This message appeared at the very end of the
copyprocess.Regardless of this, everything seems to work just fine.