When a git annex move is interrupted at a point where the content has been transferred, but not yet dropped from the remote, resuming the move will often refuse to drop the content, because it would violate numcopies.

Eg, if numcopies is 2, and there is only 1 extant copy, on a remote, git-annex move --from remote will normally ignore numcopies (since it's not getting any worse) and remove the content from the remote after transferring it. But, on resume, git-annex sees there are 2 copies and numcopies is 2, so it can't drop the copy from the remote.

This happens to me often enough to be annoying.

Perhaps some local state could avoid this problem?

--Joey

One simple way would be to drop the content from the remote before moving it to annex/objects/. Then if the move were interrupted before the drop, it could resume the interrupted transfer, and numcopies would work the same as it did when the move started.

Or, move to annex/objects/ but delay updating the location tracking to say it's in the local repo until after the drop.

Either way, a problem is that the only copy would appear missing until the move was re-run. The latter approach at least lets fsck clean up from that situation, but it could still be surprising.