rsync to s3fs mount defaults to application/octet-stream

[GoogleCodeExporter]

What steps will reproduce the problem?
1. rsync to s3fs mount
2. Check Content-Type
3. application/octet-stream even if filename extension is correctly defined
in /etc/mime.types

What is the expected output? What do you see instead?
Should use the content-type defined in mime.types instead. I am seeing
application/octet-stream even if filename extension is correctly defined in
/etc/mime.types

What version of the product are you using? On what operating system?
s3fs-r177

Please provide any additional information below.
Thanks in advance.

Original issue reported on code.google.com by premr...@gmail.com on 24 Sep 2009 at 5:01

[GoogleCodeExporter]

can use rsync --inplace as a workaround

Original comment by rri...@gmail.com on 24 Sep 2009 at 6:04

[GoogleCodeExporter]

Thanks! It works.

Original comment by premr...@gmail.com on 25 Sep 2009 at 4:41

[GoogleCodeExporter]

rsync when used without --inplace creates a random extension that it tacks onto 
the filename.  For example, if I rsync the following file:

/Canon-SD850/100CANON/IMG_0278.JPG

...the path that s3fs initially sees when creating the file is this:

/Canon-SD850/100CANON/.IMG_0278.JPG.PbkGhI

Obviously, "PbkGhI" isn't an extension that is a recognized mime type.  
(Apparently, rsync later on does a move of this file).

The attached patch solves this issue by modifying the lookupMimeType function 
to not only analyze the last extension for a matching mime type, but analyze 
the second to last extension if the last extension did not result in a match.

Original comment by moore...@gmail.com on 1 Jul 2010 at 12:34

Attachments:

• s3fs.cpp.2010-06-30-18:30:50.patch

[GoogleCodeExporter]

Original comment by dmoore4...@gmail.com on 18 Oct 2010 at 9:23

• Changed state: Started

[GoogleCodeExporter]

Fixed in r198 - applied patch and verified

Original comment by dmoore4...@gmail.com on 18 Oct 2010 at 10:18

• Changed state: Fixed