That's because your system mime config doesn't know about css files. S3cmd relies on that to identify the mime type, by itself it doesn't make any decisions about file types.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
You're right: if I do file -i style.css, I get back text/plain; charset=us-ascii. Ditto for javascript files. This is despite having entries in /etc/mime.types for .css and .js files.
I know I can override the mime-type for individual files with the --mime-type=MIME/TYPE option, but I am currently doing a sync that could include many files (some CSS, some JS, some images, etc.).
So, is there a way for s3cmd to use the file extension to determine the mime-type, instead of the magic method?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have the same issue and it's a real pain. It makes sync unusable for updating web sites, at least on Linux.
Traditionally file name suffixes are ignored on Unix systems (by http://wiki.debian.org/MIME) so just relying on magic numbers mechanism gives inconsistent results for text-based file types.
I really hope there's a way to make this work in s3cmd.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
That's because your system mime config doesn't know about css files. S3cmd relies on that to identify the mime type, by itself it doesn't make any decisions about file types.
You're right: if I do
file -i style.css, I get backtext/plain; charset=us-ascii. Ditto for javascript files. This is despite having entries in /etc/mime.types for .css and .js files.I know I can override the mime-type for individual files with the
--mime-type=MIME/TYPEoption, but I am currently doing a sync that could include many files (some CSS, some JS, some images, etc.).So, is there a way for s3cmd to use the file extension to determine the mime-type, instead of the magic method?
I have the same issue and it's a real pain. It makes sync unusable for updating web sites, at least on Linux.
Traditionally file name suffixes are ignored on Unix systems (by http://wiki.debian.org/MIME) so just relying on magic numbers mechanism gives inconsistent results for text-based file types.
I really hope there's a way to make this work in s3cmd.
This issue is also tracked at https://github.com/s3tools/s3cmd/issues/198
I created a patch and pull request.