-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Aws::S3::Object.copy_from fails cross-regions when multipart_copy: true #1083
Comments
There is no such restriction, so this is something we're going to investigate. |
I'm checking in on this issue- it's holding up some major code cleanup we have staged. I'm also happy to assist; if there's a root cause identified I can work on PR. I did some debugging on the issue originally but things got confusing once it got down into the |
👍 |
UpdateDebugged through the multipart copy today and found the bug, as well as a workaround. BugSee def source_size(options)
if options[:content_length]
options.delete(:content_length)
else
bucket, key = options[:copy_source].match(/([^\/]+?)\/(.+)/)[1,2]
@client.head_object(bucket:bucket, key:key).content_length # Uses target client instead of source client
end
end The I believe that what needs to happen is that, in WorkaroundAs you can see in the above code snippet, if target_object.copy_from(source_object, multipart_copy: true, content_length: source_object.content_length) ...it short-circuits the fetch of the |
@whazzmaster Good insights.
You are correct. What is needed is a client configured for the region of the source bucket. It should be possible to automatically extract this from the source object if it has been passed in as an instance of For situations where an object is not given, we could add the following options:
I think what I'm still considering is should we continue attempting to copy from the same region when we are not certain? If so, I think we should also rescue the 301 error an raise a more helpful error, that we could not discover the size of the source object and that they will need to pass one of the above options. Thoughts? Source client, or possibly source region. Alternatively it could pass in a source region. The SDK could construct a client for the appropriate region and then HEAD the object there. This has the additional benefit that it would allow the customer to pass in Another option is to support a HINT from the user about the size of the source object or the prefered |
@trevorrowe Ack- just pushed a PR and didn't see your response (just happened to notice I hadn't started my mail client after reboot this morning 😿) The PR extracts the client from the supplied source object passed to Conceptually though I like your idea about being more explicit at the external API, and allowing for an explicit source client to be supplied. I think the specific option keys probably depend on whether region-to-region copying should be recognized as a 'non-normal' action that requires extra options to be passed. Considering the existing ability to pass in a variety of different option types, allowing Ultimately I'd say that this PR fixes the bug, but the behavior can be robustified via more/better options to the |
We're attempting to copy objects from a bucket in one region to a bucket in another region with the multipart_copy option set to true. We've found that the operation succeeds when
multipart_copy
is not specified in theObject.copy_from
call, but as soon as we add it we instead receive anAws::S3::Errors:Http301Error
.Digging in with the aws.rb client, we additionally found that when invoking
copy_from
withmultipart_copy: true
theHEAD
call erroneously constructs an endpoint using the target region endpoint but the source region bucket, e.g.,As opposed to doing the same call without
multipart_copy: true
...Is is a known restriction that you cannot copy using multipart across regions?
The text was updated successfully, but these errors were encountered: