carrierwaveuploader / carrierwave-aws

AWS-SDK storage adapter for CarrierWave
MIT License
409 stars 107 forks source link

Uploads fail #156

Closed coding-bunny closed 4 years ago

coding-bunny commented 4 years ago

Hello,

We're running version 1.3.0 and when we try to upgrade to 1.4.0, suddenly all our uploads fail. Stuff that was working before with temporary files is now broken.

For example we have this in our seeds.rb:

artwork_file = Rack::Test::UploadedFile.new(File.open(File.join(Rails.root, 'cypress', 'fixtures', 'artwork_logo.png')))

When we use this file with any of our uploaders, we receive the following error:

Errno::ENOENT: No such file or directory @ rb_sysopen - uploads/tmp/1580716843-365815039158170-0001-8492/artwork_logo.png
/Users/olivar/RubymineProjects/customink-for-business/app/models/artwork.rb:37:in `hash_file'
/Users/olivar/RubymineProjects/customink-for-business/app/models/artwork.rb:14:in `block in <class:Artwork>'
/Users/olivar/RubymineProjects/customink-for-business/db/seeds.rb:8:in `block in <main>'
/Users/olivar/RubymineProjects/customink-for-business/db/seeds.rb:1:in `<main>'
/Users/olivar/RubymineProjects/customink-for-business/bin/rails:9:in `<top (required)>'
/Users/olivar/RubymineProjects/customink-for-business/bin/spring:15:in `<top (required)>'
bin/rails:3:in `load'
bin/rails:3:in `<main>'
Tasks: TOP => db:setup => db:seed
(See full trace by running task with --trace)

Our Artwork class has a simple uploader:

class BaseUploader < CarrierWave::Uploader::Base
  if Rails.env.development? || Rails.env.test?
    # Intentionally do not include model name in the path, because we sometimes use `BaseUploader`
    # to upload a file and then set it on model instead of using uploader instance from model.
    def store_dir
      "uploads/#{Rails.env}"
    end
  end

  # Overrides CarrierWave::Uploader::Base method in order to keep the file
  # on s3, after the object has been removed.
  def remove!
    # do nothing
  end
end
sorentwo commented 4 years ago

Your issues seem to stem from upgrading to carrierwave 2.0, and not the carrierwave-aws bump. I suggest checking the carrierwave changelog to see if there are any changes that match up with the errors your seeing: things like file hashing, tempfile handling, changes to storage directory, etc.

coding-bunny commented 4 years ago

ah good catch, I'll look into it !