-
Notifications
You must be signed in to change notification settings - Fork 4k
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
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 cp with --metadata-directive REPLACE not guessing correct Content-Type #6078
Comments
Hi @bersalazar, Thanks for pointing this out— I was able to reproduce. Marking as a bug for now. |
Hi @bersalazar, #6115 should take care of this— next V2 release will hopefully be next week. Please feel free to reach out if you're still having issues after that! |
Hi @bersalazar, After a review of the v1 behavior and the PR I mentioned in my last comment, it looks like we actually explicitly removed support for guessing mimetypes for copies in v2 now that we copy over metadata— it was only by accident that v1 supports injecting mimetypes. Even in the docs for v1 Would you be able to clarify what your particular use case is for this? We may have a current set of parameters that could work and we're hesitant to add this 'mistake' back if there's not a strong reason for it. Thanks! |
Hi @stobrien89 Thanks for the replies. The use case is indeed when copying files from bucket to bucket. The source and target buckets are the same in this case, the idea is to use |
Hi @bersalazar, I may be missing something here, but I did some testing with |
hey @stobrien89,
Content-Type is correctly set on I understand |
Hi @bersalazar, My apologies— I almost forgot you were needing to copy a single file rather than an entire directory. So the 'correct' behavior is actually found in v2 for reasons I mentioned before— if you compare debug logs between v1 and v2 for In this case, you may be better off not specifying To test, you can create a blank index.html file (or something to that effect), use Hope this helps! |
OK, thanks for the help and clarification @stobrien89, really appreciated! |
Of course— Hope this works for you! Please feel free to reach out at any time if you have any additional questions. |
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
Confirm by changing [ ] to [x] below to ensure that it's a bug:
Describe the bug
When using awscli v2 and copying a file using
aws s3 cp
with the--metadata-directive REPLACE
parameter, Content-Type is not correctly guessed for files and are set tobinary/octet-stream
after upload.This behavior is not present when running the same command from Ubuntu or when using awscli v1 from macOS.
SDK version number
aws-cli/2.1.35 Python/3.8.8 Darwin/19.6.0 exe/x86_64 prompt/off
Platform/OS/Hardware/Device
macOS 10.15.7 (Catalina)
To Reproduce (observed behavior)
aws s3 cp <bucket>/<file> <bucket>/<file> --metadata-directive REPLACE
Expected behavior
Content-type is correctly guessed by
aws s3 cp
, even if the source metadata is replaced.Logs/output
debug-logs-from-aws-s3-cp.txt
Additional context
awscli makes use of Python's mimetypes module for guessing MIME types for files, which are usually installed in
/etc/mime.types
in Ubuntu, however, this is not the directory where the mime.types file is present for macOS. They are found in/etc/apache2/mime.types
which the mimetypes module has listed as knownfiles for fetching MIME types. In spite of this, awscli doesn't seem to pick up them up.This issue is not present in awscli v1, where the
--metadata-directive REPLACE
parameter guesses correctly the Content-Types when copying.The text was updated successfully, but these errors were encountered: