Carrierwave upload hits Errno::EEXIST - file exists error - carrierwave

Question

Have installed a rails3.2.18 application on two machines: a Ubuntu 14.04 and osx 10.6 for testing purposes.
Submitting a file for upload on the OS X box (these files are intentionally big) with carrierwave returns Errno::EEXIST in [...] controller specifying:
File exists - /Users/user/app/releases/20141018152115/public/uploads
This error is not occurring on Ubuntu installation. public/uploads exists because it needs to be a symlink to shared/public/uploads for persistence requirements. The capistrano3 deploy command
set :linked_dirs, %w{bin log tmp/pids tmp/cache tmp/sockets vendor/bundle public/system public/uploads}
sets the symlink up. For good measure I ran deploys on both machines sequentially to isolate any app issues.
So this again appears to be an OSX issue. One assumption is that the given stage file is somehow misconfigured for OSX, although the (only) user with admin rights is appropriately specified:
set :deploy_to, '/Users/osxuser/app'
set :use_sudo, false
set :deploy_user, 'osxuser'
Another assumption is related to the migration from Capistrano2 to Capistrano3, as this osX server did not have such issues prior to the upgrade.
How can the 'file exists' error be eliminated?
Update
/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'
the stack trace appears to be wanting to mkdir carrierwave (0.9.0) lib/carrierwave/sanitized_file.rb:290:in mkdir!
the carrierwave uploader is specified as follows
def store_dir
"uploads/#{model.class.to_s.underscore}/#{model.quote.cart_id}_#{model.quote.cart.created_at}_/#{model.quote_id}/#{model.id}"
end

Answer 1

This is a pitfall when creating an OS-X 'alias' instead of a symlink.
(Not in the actual gems resp. any specific version – I experienced the same today with rails 5.0.0.1, ruby 3.2.1 and carrierwave 0.11.2.)
It turned out that I had accidently created not a symlink but an alias using the OS X Finder (which technically is not a symlink). When carrierwave then tries to create the folder structure FileUtils.mkir_p raises an error on trying to (re)create the (existing) alias as a directory.
rm ./app/releases/20141018152115/public/uploads
ln -s ./app/shared/public/uploads ./app/releases/$timestamp/public/uploads
should do the trick.
[EDIT: Clarified the actual root cause is not in ruby, rails or the gems in use]