# Attachment\_fu and bmp files not working

**URL:** <https://www.ruby-forum.com/t/attachment-fu-and-bmp-files-not-working/113792>\
**Category:** Rails\
**Created:** [September 4, 2007, 11:53pm UTC](https://www.ruby-forum.com/t/attachment-fu-and-bmp-files-not-working/113792 "2007-09-04T23:53:42Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![scott](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/3e96dc/32.png) [@scott](https://www.ruby-forum.com/u/scott)\
**Post date:** [September 4, 2007, 11:53pm UTC](https://www.ruby-forum.com/t/attachment-fu-and-bmp-files-not-working/113792/1 "2007-09-04T23:53:42Z")

</div>

I have been using attachment\_fu for a while now with jpg, gif, png  
without any trouble. I recently tried to upload a bmp and got:

“Content type is not included in the list”

So, I added the following to the @@content\_types in attachment\_fu:

‘image/bmp’, ‘image/x-bmp’

Same problem.

Closer inspection of the content\_type of the file was coming through  
as ‘application/octet-stream’.

I am using RMagick as the image processor.

Has anyone else run into this problem with bmp and attachment\_fu? Is  
there another content\_type that will resolve this? I tried adding  
‘application/octet-stream’ to my content types but this didn’t work  
nor feel right.

Thanks,

Scott

---

<div class="post-metadata">

**Author:** ![scott](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/3e96dc/32.png) [@scott](https://www.ruby-forum.com/u/scott)\
**Post date:** [September 5, 2007, 1:18am UTC](https://www.ruby-forum.com/t/attachment-fu-and-bmp-files-not-working/113792/2 "2007-09-05T01:18:51Z")

</div>

On 04 Sep 2007, at 23:40, Scott wrote:

> Closer inspection of the content\_type of the file was coming through  
> as ‘application/octet-stream’.
> 
> I am using RMagick as the image processor.
> 
> Has anyone else run into this problem with bmp and attachment\_fu? Is  
> there another content\_type that will resolve this? I tried adding  
> ‘application/octet-stream’ to my content types but this didn’t work  
> nor feel right.

application/octet-stream is just a generic file stream, i.e. without  
a known mime type. You could patch attachment\_fu (the code of the  
plugin is so nice and neat you’ll have no problem finding the right  
place) to use the .bmp extension to determine the file type (or use  
the similar directions at [http://blog.airbladesoftware.com/2007/8/8/](http://blog.airbladesoftware.com/2007/8/8/)  
uploading-files-with-swfupload).

Best regards

Peter De Berdt

---

<div class="post-metadata">

**Author:** ![scott](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/3e96dc/32.png) [@scott](https://www.ruby-forum.com/u/scott)\
**Post date:** [September 7, 2007, 5:05pm UTC](https://www.ruby-forum.com/t/attachment-fu-and-bmp-files-not-working/113792/3 "2007-09-07T17:05:07Z")

</div>

I hope I’m not fragmenting your thread here but do any of you guys  
know how to get attachment\_fu to send a ‘healthy’ image file up to S3?  
I’ve followed this in detail my Windows XP development box, only a  
ZERO k file is being uploaded to S3 for any type of file from .png  
to .gif to .jpg.  
Obviously, I will run my application eventually on a Linux server but  
it sure would be nice to see my photos in development.  
Thank you,  
Kathleen  
removed\_email\_address@domain.invalid

---

<div class="post-metadata">

**Author:** ![scott](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/3e96dc/32.png) [@scott](https://www.ruby-forum.com/u/scott)\
**Post date:** [September 7, 2007, 2:53am UTC](https://www.ruby-forum.com/t/attachment-fu-and-bmp-files-not-working/113792/4 "2007-09-07T02:53:40Z")

</div>

Thanks for pointing me the right direction Peter.

Seems that all I needed to do was augment the uplaoded\_data= method  
to:

```
    if file_data.content_type == 'application/octet-stream' &&

```

File.extname(uploaded\_data.original\_filename) == “.bmp” then  
self.content\_type = ‘image/bmp’  
else  
self.content\_type = file\_data.content\_type  
end

That seems to have done the trick.

Scott