That is incorrect... The first command passes through the aws-cli's mime-type checker and only when it can't find the type it will set it to octet-stream... More info here: github.com/aws/aws-cli/blob/9d8353...
However if you do the second command without (which probably uses the AWS SDK) that happens, you should define the 'Content-Type' header in the 'options' ;-)
For me, it did replace the content type from image/jpeg to binary/octet-stream, since I only had jpeg images I was able to just add that to the command.
It also changed the permission of the object, so I had to recreate the object acl
# List current object acl
awss3apiget-object-acl--bucketbucket-name--keyobject-key# full copy command
awss3cps3://bucket-names3://bucket-name--metadata-directiveREPLACE--recursive--cache-controlmax-age=2592000--content-typeimage/jpeg--aclpublic-read
Be careful with the first command. It replaces all metadata and sets the content type to binary/octet-stream
That is incorrect... The first command passes through the aws-cli's mime-type checker and only when it can't find the type it will set it to octet-stream... More info here: github.com/aws/aws-cli/blob/9d8353...
However if you do the second command without (which probably uses the AWS SDK) that happens, you should define the 'Content-Type' header in the 'options' ;-)
For me, it did replace the content type from
image/jpeg
tobinary/octet-stream
, since I only had jpeg images I was able to just add that to the command.It also changed the permission of the object, so I had to recreate the object acl
Useful info on acl
docs.aws.amazon.com/AmazonS3/lates...