Attachment_fu on Windows?

Has anyone had any success using Rick O.'s “attachment_fu” plugin
while developing on a Windows machine?

I’ve been looking for solutions to the issue described here
http://railsweenie.com/forums/3/topics/1257 but haven’t heard anything
yet.

The issue is that attachment_fu fails to record the uploaded file’s size
value properly, causing its validations to fail.

I’ve been adding logger messages into the attachment_fu code to see
what’s causing my problems on Windows. In my case it’s not properly
assigning the “size” attribute.

In “attachment_fu.rb”, there is the following method:

def set_size_from_temp_path
self.size = File.size(temp_path) if save_attachment?
end

Based on logger messages, I’ve determined that save_attachment? returns
true, the temporary file does exist on my system, but that file’s
File.size parameter returns zero, so it saves self.size as zero, thus
failing the validations.

In my case, the uploaded_data IS properly assigned, and the image is
saved to the disk in the appropriate place. The only problem I’ve found
is with the size parameter. To complicate matters, the behavior is not
consistent. Occasionally it saves a size value, but most of the time the
size is zero.

I’ve created a brand new Rails app and model which uses only
attachment_fu’s required fields to test these conclusions.

On my system I’m using:

  • Rails 1.2.2
  • Windows XP
  • MySQL 5.0
  • ImageMagick-6.3.2-Q16
  • mini_magick 1.2.0

When attachment_fu creates thumbnails, the thumbnail files ARE saved
with the correct size in their model. I don’t know why the original
files aren’t.

Does this have to do with Windows “Tempfile” issues? I tried out a
“windows_tempfile_fix” plugin but it required Ruby 1.8.4 where I have
1.8.5.

Does anyone have any ideas? Thanks,

Jeff

My guess is it’s the Ruby version and the temp file issue that is your
problem. I took the following steps and was able to get it to work on
Windows

  1. Installed rmagick via the instructions on
    http://rubyforge.org/projects/rmagick/

  2. Installed AttachmentFU via

    ruby script/plugin install
    http://svn.techno-weenie.net/projects/plugins/attachmen_fu/

  3. In C:\ruby\lib\ruby\1.8\tempfile.rb

    Modified per

http://blog.teksol.info/articles/2006/12/08/rmagick-and-jpeg-datastream-contains-no-image
# for the “JPEG datastream contains no image” bug
# @tmpfile = File.open(tmpname, File::RDWR|File::CREAT|
File::EXCL, 0600)
@tmpfile = File.open(tmpname, File::RDWR|File::CREAT|File::EXCL|
File::BINARY, 0600)

You might also want to review
http://clarkware.com/cgi/blosxom/2007/02/24
to see if you haven’t missed anything.

Eric

Eric N. wrote:

My guess is it’s the Ruby version and the temp file issue that is your
problem. I took the following steps and was able to get it to work on
Windows
…snip…

Eric, thanks.

I looked over the steps and it does seem that I’ve done all those
things, I confirmed that I’ve already made that change to tempfile.rb.

I’m using mini_magick, though–I had been using file_column and Rmagick
and the reason I switched to attachment_fu was to take advantage of the
streamlined mini_magick library.

I’ll give it a try with Rmagick and see how it goes.

Jeff

Jeff C.man wrote:

Eric N. wrote:

My guess is it’s the Ruby version and the temp file issue that is your
problem. I took the following steps and was able to get it to work on
Windows
…snip…

I just did a fresh installation with a new Rails app, a new model and a
new install of attachment_fu using Rmagick as the image processor, and I
received the same results. The file’s “size” attribute is consistently
defined as zero.

I swapped out attachment_fu for acts_as_attachment and it works
successfully, the file’s “size” attribute sets properly. Unfortunately
it looks like acts_as_attachment only works with Rmagick.

I’ve been exploring through the workings of attachment_fu but I don’t
understand it completely yet, so I don’t know why the temp file’s size
attribute doesn’t get set properly.

Anyone have any ideas? Thanks,

Jeff

Eric N. wrote:

How about rolling back to 1.8.4 just to verify whether it’s the ruby
release?

Good idea–tried it, installed Ruby 1.8.4 and fresh installs of Rails
and Rmagick, and got the same results.

I’m a little unclear on the usage of the Tempfile class. What would be
a good way to run a simple discrete test case of Tempfile, to see if
it’s working properly on my system?

Jeff

I also encountered this problem with attachment_fu. I tested it with
the
tempfile patch as well.

Quite maddening actually since I don’t have a solution for it.

Adam

How about rolling back to 1.8.4 just to verify whether it’s the ruby
release?

Jeff,

If you want, email me your zipped app and I’ll check if it works in my
environment.

Eric

Adam R. wrote:

I also encountered this problem with attachment_fu. I tested it with
the
tempfile patch as well.

Quite maddening actually since I don’t have a solution for it.

Adam

Glad I’m not the only one! If I could just figure out why the file’s
size is returning zero, it seems it would clear up the issue. I’m
trying to work out how to test the Tempfile class itself right now, to
see if that’s the root of the problem.

Jeff

I’m stuck like everyone else on the “0” filesize. Everything else
seems to work however.

Here is a step-by-step blog post on how my dev environment is setup:

http://blog.72bit.com/2007/03/12/attachment_fu-on-windows/

Wes

Well I finally was able to reproduce the infamous zero size error. I’m
not sure if it’s the same one your talking about but if so I think I
have some more clues as to the cause and a possible workaround.

First, I didn’t have any problems before when I save the new image via
the parent object via

house.images << new_image

Saved via the parent

house.save

I also modified the attachment_fu a bit to accept .bmp files as images
and everything continued to work. When I removed the parent from the
save operation via

new_image.house = house
new_image.save

all the sudden the .bmp files stopped working with the zero size
error. So I started looking through the code and noticed that for some
reason the .bmp files are being sent as Files and not StringIOs. I
haven’t looked into why one is a StringIO and the other is a File but
I’m guessing it has something to do with the content type and Mongrel.
Regardless if it’s a file it took a different path through the code.

Here’s the uploaded_data=(file_data) method where the the path split.
By adding in the read and commenting out setting the path I was able
to fix it on my machine.

def uploaded_data=(file_data)
    return nil if file_data.nil? || file_data.size == 0
    self.content_type = file_data.content_type
    self.filename     = file_data.original_filename if respond_to?

(:filename)
if file_data.is_a?(StringIO)
file_data.rewind
self.temp_data = file_data.read
else
self.temp_data = file_data.read
#self.temp_path = file_data.path
end
end

Unfortunately I don’t know what repercussions the fix might have.
Could the prior posters with the error verify if this fixes the zero
size error? Remember to restart your server after the change.

Eric

Wes wrote:

I’m stuck like everyone else on the “0” filesize. Everything else
seems to work however.

Here is a step-by-step blog post on how my dev environment is setup:

http://blog.72bit.com/2007/03/12/attachment_fu-on-windows/

Wes

It’s not a perfect solution, but Rails Weenie user wfn found a
workaround:

http://railsweenie.com/forums/3/topics/1257#posts-4895

The problem seems to be that, on Windows, the temporary file’s size
doesn’t register fast enough when the file is created, so adding a 1 or
2 second delay before processing it seems to work.

Not ideal, but at least it’s something.

Jeff

Eric N. wrote:

Unfortunately I don’t know what repercussions the fix might have.
Could the prior posters with the error verify if this fixes the zero
size error? Remember to restart your server after the change.

Thanks Eric, I’ll test this in my app and let you know what happens.

Jeff

Eric N. wrote:

Unfortunately I don’t know what repercussions the fix might have.
Could the prior posters with the error verify if this fixes the zero
size error? Remember to restart your server after the change.

Eric,

Your solution seems to have done the trick! I took out the “sleep” fix
that I’d previously added, entered your change to attachment_fu.rb and
the files upload properly with the correct size now. Thanks!

Jeff

Hmm…

I had a different, but maybe related, problem with attachment_fu on
XP. Coincidentally, I just sent an email to Rick about five minutes
ago.

To rephrase my email to him>>

I added this line of code at line 161 in attachment_fu.rb to fix a
problem on Windows machines where all incoming images are corrupted by
extraneous line-feed characters. I am developing on windows
currently, so this stung me.

At line 161 of attachment_fu.rb:
tmp.binmode

The binary mode issue on Windows is discussed on this wiki page:
http://wiki.rubyonrails.org/rails/pages/HowtoUploadFiles if you’re
interested in more info. This should not harm the app on linux based
on my prior experience with this bug (in my previous photo handling
model). Thanks again,

Eric

On Mar 30, 6:48 pm, Jeff C.man [email protected]

To get things working with S3 and windows, I changed:

  def temp_data
    if save_attachment?
      f = File.new( temp_path )
      f.binmode
      return f.read
    else
      return nil
    end
  end

(before, the method body was save_attachment? ? File.read( temp_path ) :
nil )

It’s kind of ugly as it assumes attachments are binary, but it works in
my situation.

Jeff C.man wrote:

Eric N. wrote:

Unfortunately I don’t know what repercussions the fix might have.
Could the prior posters with the error verify if this fixes the zero
size error? Remember to restart your server after the change.

Eric,

Your solution seems to have done the trick! I took out the “sleep” fix
that I’d previously added, entered your change to attachment_fu.rb and
the files upload properly with the correct size now. Thanks!

Jeff

Adam wrote:

To get things working with S3 and windows, I changed:

  def temp_data
    if save_attachment?
      f = File.new( temp_path )
      f.binmode
      return f.read
    else
      return nil
    end
  end

(before, the method body was save_attachment? ? File.read( temp_path ) :
nil )

I’m not having any problems with attachment_fu on windows and all is
well. But when I move over the code to my hosting space at dreamhost, I
get an error saying,

“You have a nil object when you didn’t expect it!
The error occurred while evaluating nil.symbolize_keys”

This error happens only when the :storage option of “has_attachment”
method is set to :s3. Any ideas?


Aswin

This solution worked for me. I was using :db_file

What an ordeal.

Good gravy Eric N.'s solution works! I had tried everything else,
thank you, it only remains to see how this will affect the application
when it’s time to deploy to the server.

I’m a newbie in Ruby and using attachment_fu on Windows Vista. I first
had some issues to have it working properly. The size of the file was
incorrect set to 0, the empty file was created (and a row was added in
my attachment table). However, I notice that this was caused by
incorrect file permissions. I got “Permission denied”. When I explicit
increased rights (+r+w+x) on the folder where the file is stored, it
seems to work just fine.

Since I wasted some time there, I hope to save those hours for someone
else :slight_smile:

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs