-
Notifications
You must be signed in to change notification settings - Fork 2.8k
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
TransferManager.copy() performs GetObjectMetadata request without passing sourceVersionId #1009
Comments
Thank you for reporting this. I will look into it and get a fix out. We also love pull requests if you'd like to contribute one! |
Thanks for the response! I could certainly fix this myself because it's such a simple change, but I couldn't help but notice that the s3 module is one of the very few that doesn't even seem to have any tests. Are there really no tests for the S3 Java SDK? Should I just submit a PR for the fix itself (just a one-liner)? |
Yes I apologize about the lack of tests. We have a large number of them internally but we don't currently publish them publicly, but we're working on it. Feel free to just submit the change to the |
I have a fix for this upstream. It should be available in our Monday release next week (2/6). |
Thank you! |
When TransferManager.copy() performs a GetObjectMetadata request, it always requests the metadata for the latest object version (i.e., it doesn't pass in a versionId), even though it's possible for the CopyObjectRequest to specify a sourceVersionId. When constructing the GetObjectMetadataRequest, it should also pass in copyObjectRequest.getSourceVersionId().
There are several bugs that could be caused by not doing this if a non-current version of an object is being copied:
The text was updated successfully, but these errors were encountered: