【问题标题】:Carrierwave upload hits Errno::EEXIST - file exists errorCarrierwave 上传命中 Errno::EEXIST - 文件存在错误
【发布时间】:2014-10-20 09:07:54
【问题描述】:

已在两台机器上安装了 rails3.2.18 应用程序:Ubuntu 14.04 和 osx 10.6 用于测试目的。

在 OS X 机器上提交要上传的文件(这些文件故意很大),使用carrierwave 返回Errno::EEXIST in [...] controller 指定:

File exists - /Users/user/app/releases/20141018152115/public/uploads

在安装 Ubuntu 时不会发生此错误。 public/uploads 之所以存在,是因为它需要成为shared/public/uploads 的符号链接以满足持久性要求。 capistrano3 部署命令

set :linked_dirs, %w{bin log tmp/pids tmp/cache tmp/sockets vendor/bundle public/system public/uploads}

设置符号链接。为了更好地衡量,我在两台机器上依次运行部署以隔离任何应用程序问题。

所以这似乎又是一个 OSX 问题。一个假设是给定的阶段文件在某种程度上为 OSX 配置错误,尽管适当地指定了(唯一)具有管理员权限的用户:

set :deploy_to, '/Users/osxuser/app'
set :use_sudo, false
set :deploy_user, 'osxuser'

另一个假设与从 Capistrano2 到 Capistrano3 的迁移有关,因为此 osX 服务器在升级之前没有此类问题。

如何消除“文件存在”错误?

更新

/Users/osxuser/.rvm/rubies/ruby-1.9.3-p194/lib/ruby/1.9.1/fileutils.rb:244:in `mkdir'
/Users/osxuser/.rvm/rubies/ruby-1.9.3-p194/lib/ruby/1.9.1/fileutils.rb:244:in `fu_mkdir'
/Users/osxuser/.rvm/rubies/ruby-1.9.3-p194/lib/ruby/1.9.1/fileutils.rb:221:in `block (2 levels) in mkdir_p'
/Users/osxuser/.rvm/rubies/ruby-1.9.3-p194/lib/ruby/1.9.1/fileutils.rb:219:in `reverse_each'
/Users/osxuser/.rvm/rubies/ruby-1.9.3-p194/lib/ruby/1.9.1/fileutils.rb:219:in `block in mkdir_p'
/Users/osxuser/.rvm/rubies/ruby-1.9.3-p194/lib/ruby/1.9.1/fileutils.rb:205:in `each'
/Users/osxuser/.rvm/rubies/ruby-1.9.3-p194/lib/ruby/1.9.1/fileutils.rb:205:in `mkdir_p'
carrierwave (0.9.0) lib/carrierwave/sanitized_file.rb:290:in `mkdir!'
carrierwave (0.9.0) lib/carrierwave/sanitized_file.rb:209:in `copy_to'
carrierwave (0.9.0) lib/carrierwave/uploader/cache.rb:131:in `block in cache!'
carrierwave (0.9.0) lib/carrierwave/uploader/callbacks.rb:17:in `with_callbacks'
carrierwave (0.9.0) lib/carrierwave/uploader/cache.rb:122:in `cache!'
carrierwave (0.9.0) lib/carrierwave/mount.rb:327:in `cache'
carrierwave (0.9.0) lib/carrierwave/mount.rb:179:in `production_file='
carrierwave (0.9.0) lib/carrierwave/orm/activerecord.rb:38:in `production_file='
activerecord (3.2.18) lib/active_record/attribute_assignment.rb:85:in `block in assign_attributes'
activerecord (3.2.18) lib/active_record/attribute_assignment.rb:78:in `each'
activerecord (3.2.18) lib/active_record/attribute_assignment.rb:78:in `assign_attributes'
activerecord (3.2.18) lib/active_record/persistence.rb:216:in `block in update_attributes'
activerecord (3.2.18) lib/active_record/transactions.rb:313:in `block in with_transaction_returning_status'
activerecord (3.2.18) lib/active_record/connection_adapters/abstract/database_statements.rb:192:in `transaction'
activerecord (3.2.18) lib/active_record/transactions.rb:208:in `transaction'
activerecord (3.2.18) lib/active_record/transactions.rb:311:in `with_transaction_returning_status'
activerecord (3.2.18) lib/active_record/persistence.rb:215:in `update_attributes'
app/controllers/bozzadocuments_controller.rb:62:in `block in update'

堆栈跟踪似乎想要 mkdir carrierwave (0.9.0) lib/carrierwave/sanitized_file.rb:290:in mkdir!

载波上传器指定如下

  def store_dir
    "uploads/#{model.class.to_s.underscore}/#{model.quote.cart_id}_#{model.quote.cart.created_at}_/#{model.quote_id}/#{model.id}"
  end

【问题讨论】:

  • 你能弄清楚 gem 在抛出错误时试图做什么吗?即它是试图写信给/uploads,还是无法导航符号链接,例如由于权限,还是其他原因?如果您无法从堆栈跟踪等中看到,那么您可以使用 dtruss 来调试它作为最后的手段。您是否需要用尾部斜杠告诉它/uploads/ 来表示“写入此目录”而不是“写入此特定文件路径”?
  • 我已更新问题以包含堆栈跟踪。预先存在的符号链接似乎有问题

标签: carrierwave osx-snow-leopard capistrano3


【解决方案1】:

在创建 OS-X 的“别名”而不是符号链接时,这是一个陷阱。

(在实际的 gems 中没有任何特定的版本——我今天在 rails 5.0.0.1、ruby 3.2.1 和carrierwave 0.11.2 中遇到了同样的情况。)

事实证明,我使用 OS X Finder 创建的不是符号链接,而是别名(从技术上讲,它不是符号链接)。当carrierwave 然后尝试创建文件夹结构FileUtils.mkir_p 尝试(重新)创建(现有)别名作为目录时引发错误。

rm ./app/releases/20141018152115/public/uploads ln -s ./app/shared/public/uploads ./app/releases/$timestamp/public/uploads

应该可以解决问题。

[编辑:澄清实际根本原因不在 ruby​​、rails 或使用中的 gems]

【讨论】:

  • 哦,尽管问题的年代久远,您仍能做出回应。 ++
  • 这是一个永恒的问题,因为它与实际版本(甚至实际 gem 载波)无关,但在 OSX 上是一个常见的陷阱,所以我认为这可能对你仍然有帮助或未来的访客:)
  • 它与版本无关的事实应该在改进它的答案中。
猜你喜欢
  • 2011-05-29
  • 2017-05-14
  • 1970-01-01
  • 2021-09-27
  • 1970-01-01
  • 1970-01-01
  • 2016-11-10
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多