Thursday, April 19, 2007

Tempfile issues

I recently started using attachment_fu for uploading images to my rails application.

First I had all the normal issues with the binary tempfiles on windows (ruby's Tempfile class doesn't set the mode of the new file to binary, so every time a '\n' is in the JPG, it becomes '\n\r') which there is a rails plugin to fix (search for rails_tempfile_fix.)

Then I had issues with attachment_fu claiming "size not in list" whenever I uploaded files in windows. Some posts claim that this is caused by windows not correctly telling ruby when it is done creating the tempfile, causes ruby to receive the wrong filesize. Either way, a partial fix is to tell your rails action to "sleep" for a couple of seconds so that windows can finish writing the file before ruby tries to process it. This hack actually didn't work that well for me, but either way the issue (supposedly) only affects windows and my deploy environment is a *nix box so I stopped worrying about it.

Now a new issue: On my deployment machine (rails/fcgid/apache/CentOS), certain images can cause an exception to be raised. Let's call the image XYZ.jpg. Debugging a bit, I found that attachment_fu/Tempfile does the following:

in the directory RAILS_ROOT/tmp/attachment_fu:

For n = 1..10, do:
let tmpfile_name = {current_timestamp}_XYZ_{n}.jpg
let lockfile_name = {current_timestamp}_XYZ_{n}.jpg.lock

make sure tmpfile_name and lockfile_name exist

mkdir(lockfile_name)
create tmpfile_name
rm(lockfile_name)
return tmpfile_name
end



This fails at the line mkdir(lockfile_name) when you try to upload XYZ.jpg. An error is raised saying that permission is denied on creating that file. Now, let's say I have another JPG and name it XYZ.jpg and upload it as well. This does not cause the problem. I'm fairly baffled as the only factor in difference is the content of the file, which isn't even being used in this context.

Possible culprits: Rails? attachment_fu? ruby? CentOS?

Either way, if you set the permissions of the attachment_fu/ directory to 777, it works for now.

No comments: