From 5645017a03910f787c5eac9eaacbad23ca53697b Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Fri, 20 Jan 2023 11:23:04 -0400 Subject: [PATCH] comment --- ..._959f6081cb3cb777ea4fad70bad07da3._comment | 30 +++++++++++++++++++ 1 file changed, 30 insertions(+) create mode 100644 doc/todo/copy_with_both_--to_and_--from_/comment_6_959f6081cb3cb777ea4fad70bad07da3._comment diff --git a/doc/todo/copy_with_both_--to_and_--from_/comment_6_959f6081cb3cb777ea4fad70bad07da3._comment b/doc/todo/copy_with_both_--to_and_--from_/comment_6_959f6081cb3cb777ea4fad70bad07da3._comment new file mode 100644 index 0000000000..1a15c3943f --- /dev/null +++ b/doc/todo/copy_with_both_--to_and_--from_/comment_6_959f6081cb3cb777ea4fad70bad07da3._comment @@ -0,0 +1,30 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 6""" + date="2023-01-20T15:11:50Z" + content=""" +I've started on an implementation of this, in the `fromto` branch. + +Downloading to a local temp file has some complications which make me want +to avoid it is possible. For one thing, these temp files would have to +somehow get cleaned up after an interrupted move. For another, two +concurrent move processes from different remotes to different remotes would +need to either use separate temp files (wasting disk space) or locking so +only one uses the temp file at one time. The existing code in +Annex.Transfer would have to be parameterized with the temp file to use, +but then the transfer log/lock files that are used by that code would be +problematic. So perhaps that Annex.Transfer code could not be reused, but +then it would need to independeantly deal with resuming, locking, and stall +detection. + +So, I'm considering downloading --from the remote as usual, populating the +local annex with the content, sending that --to the remote, and then +dropping the local copy. That has its own complications, but they seem +mostly less. Although there are two small races that I have not been able +to resolve yet, which would result in `git-annex move --from --to`, when +run concurrently with a `git-annex get` type process, result in the local +copy not being present at the end (see [[!commit a46c385aec2584419330c5dbb571c19ceb92f6fb]]). +That would be surprising behavior, but also unlikely to happen. This approach +also has the problem that, when the file is unlocked, the unlocked file would +get populated after downloading the content, which would be unncessary work. +"""]] -- 2.30.2