May not be handling hash properly?

[hoopsho]

Using the following values for that attachment:

...
:path => "/:view_key/:style/:hash",
:use_timestamp => false,
:hash_secret => "hash.secret",
:hash_data => ":class/:attachment/:id/:style/:updated_at"
...

The process works, and the styles are generated on S3, but the hash is different. The image from paperclip/rails perspective thinks that it has a different path with a different hash than what is actually out on S3.

S3:
/l3n08oq9wqo18wgq8454/post/d3610c38d4d3c9efc8fa3ad92bbebe0be2236d49

Rails/paperclip:
/l3n08oq9wqo18wgq8454/post/75953d644e3684c584d25e401ee250b0ce36ca78

If I remove the hashed path requirements, the code works great and happily places the files out on S3 with the default pathing.

Thoughts as to what may be the problem with using a hashed path? Is it that the code is not interrogating the hash_data and hash_secret when creating the file out on s3? or perhaps a mismatch in using the updated_at field?

Thanks,
Chris.

[Bertg]

Hey,

This could indeed be related to a date attribute being updated during the background processing. Maybe it also could have something to do with the url_with_processed method (https://github.com/jstorimer/delayed_paperclip/blob/master/lib/delayed_paperclip.rb#L120)

Could you verify any of these cases? I don't have much time this week to investigate, but could make some time if I know what to fix...

[hoopsho]

I cannot figure it out. There has to be two updates happening to the model, one of them prior to uploading to S3 and hte other prior to saving the record the second time in the DB.

[Bertg]

Can you have a look at this issue: #34

It describes issues with the url method, and how this can be fixed.

I'd like to know if reverting to the original url method works for you.

[hoopsho]

My default config:
:path => "/:view_key/:style/:hash"
:use_timestamp => false
:hash_secret => SECRET_HASH
:hash_data => ":class/:attachment/:id/:style/:updated_at"

I tried the following combinations:

url(:post)
url(:post, true)
url_with_processing(:post)
url_with_processing(:post, true)
url_without_processing(:post)
url_without_processing(:post, true)

all of which provide a different url than what is actually uploaded to S3 during the DJ process.

So maybe i am not making the right changes, but it does not seem to change anything.

[Bertg]

Hi,

I was wondering if this problem still exists in the latest git HEAD version?

If not, could you try to use the ":url_with_processing => false" option, and see if that fixes your issue.

[hoopsho]

Hey,

Yea, still the same issue. I tried pulling in your repo via git and configuring the image params with url_with_processing set to false... same problem as before. the image gets placed in a different location than the URL references.

[Bertg]

Sorry, but with the given information I can not help you out.

I've assigned this to jstorimer, hoping he can help you with this.

[hoopsho]

I will gladly provide more information, just let me know what more is needed.

[dalssoft]

The same problem here, using local storage in Dev.

Without /:hash/ it works fine.

Paperclip::Attachment.default_options.update({
  :url => "/system/images/:class/:id/:attachment/:style/:hash/:basename"
})

[dmitry]

Problem is still exists. The reason of it that worker is triggering save on model, and it updates updated_at field. :updated_at and :hash interpolators are related from the model updated_at attribute value.

[dmitry]

Fixed with hacking into the activerecord callback:

  before_save do
    if photo.job_is_processing
      write_attribute(:photo_updated_at, photo_updated_at_was)
    end
  end

[coneybeare]

For me the fix was similar. I have the <attachment>_processing column setup

before_save do
  avatar_updated_at = avatar_updated_at_was if avatar_processing
end

[abrbhat]

Having the same issue. dmitry's hack working good for now.
Edit: Actually dmitry's hack is only keeping the filename in database same. The filename of the actual file is still different.

[dmitry]

@abrbhat I've switched to https://github.com/janko-m/shrine, more modular (easier to follow the code) and predictable behavior.