27 lines
1.2 KiB
Markdown
27 lines
1.2 KiB
Markdown
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.
|