git-annex/doc/todo/interruped_move_resume.mdwn

28 lines
1.2 KiB
Text
Raw Normal View History

2020-07-15 01:44:31 +00:00
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]]
2020-07-16 00:42:53 +00:00
> 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.