mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages 1 Wiki Activity Actions

move: Improve resuming a move that was interrupted after the object was transferred

Browse source 
In cases where numcopies checks prevented the resumed move from dropping
the object from the source repository, it now relies on a log of recent
moves to replicate the behavior of the interrupted command.

Performance: Probably noticable impact, since it has to add to the log,
check the log, and remove from the log. Seems worth it to avoid this
annoying edge case. The log functions are pretty well optimised to avoid
unncessary work.

An performance improvement to make later would be to avoid cleanup doing
anything if it's not written to the log file, and has confirmed that the
log file does not contain the log line.

This commit was sponsored by Jake Vosloo on Patreon.
This commit is contained in:
Joey Hess 2020-10-21 10:31:56 -04:00
parent 363acfb55b
commit 0133b7e5a8
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
5 changed files with 114 additions and 19 deletions
Download patch file Download diff file Expand all files Collapse all files

22
doc/todo/interruped_move_resume.mdwn
View file

@ -8,7 +8,9 @@ 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.
This happens to me often enough to be annoying. Note that being interrupted
during checksum verification makes it happen, so the window is relatively
wide.
I think it can also happen with move --to, although I can't remember seeing
that.
@ -61,3 +63,21 @@ Perhaps some local state could avoid this problem?
>
> > This is complex to implement, but it avoids the gotchas in the earlier
> > ideas, so I think is best. --[[Joey]]
> > > Implementation will involve willDropMakeItWorse,
> > > which is passed a deststartedwithcopy that currently comes from
> > > inAnnex/checkPresent. Check the log, and if
> > > the interrupted move started with the move destination
> > > not having a copy, pass False.
Are there any situations where this would be surprising? Eg, if git-annex
move were interrupted, and then a year later, run again, and proceeded
to apparently violate numcopies?
Maybe, OTOH I've run into this problem probably weeks after the first move
got interrupted. Eg, if files are always moved from repo A to repo B,
leaving repo A empty, this problem can cause stuff to build up on repo A
unexpectedly. And in such a case, the timing of the resumed move does not
matter, the user expected files to always get eventually moved from A.
[[fixed|done]] --[[Joey]]