Error: EEXIST, file already exists

[fivetwentysix]

file changed templates/application.hbs
EEXIST, file already exists '/Users/fivetwentysix/testapp/tmp/caching-writer-dest-dir_GE6biD.tmp'
Error: EEXIST, file already exists '/Users/fivetwentysix/testapp/tmp/caching-writer-dest-dir_GE6biD.tmp'
    at Error (native)
    at Object.fs.symlinkSync (fs.js:852:18)
    at symlink (/Users/fivetwentysix/testapp/node_modules/ember-cli/node_modules/symlink-or-copy/index.js:82:14)
    at Function.symlinkOrCopySync (/Users/fivetwentysix/testapp/node_modules/ember-cli/node_modules/symlink-or-copy/index.js:58:5)
    at /Users/fivetwentysix/testapp/node_modules/ember-cli/node_modules/broccoli-sourcemap-concat/node_modules/broccoli-caching-writer/index.js:103:21
    at lib$rsvp$$internal$$tryCatch (/Users/fivetwentysix/testapp/node_modules/ember-cli/node_modules/promise-map-series/node_modules/rsvp/dist/rsvp.js:489:16)
    at lib$rsvp$$internal$$invokeCallback (/Users/fivetwentysix/testapp/node_modules/ember-cli/node_modules/promise-map-series/node_modules/rsvp/dist/rsvp.js:501:17)
    at lib$rsvp$$internal$$publish (/Users/fivetwentysix/testapp/node_modules/ember-cli/node_modules/promise-map-series/node_modules/rsvp/dist/rsvp.js:472:11)
    at lib$rsvp$asap$$flush (/Users/fivetwentysix/testapp/node_modules/ember-cli/node_modules/promise-map-series/node_modules/rsvp/dist/rsvp.js:1290:9)
    at process._tickCallback (node.js:355:11)

Happens when I save any file with ember serve running.

This happens on a brand new project created with ember-cli-0.1.15

Here's a sample repo: https://github.com/fivetwentysix/ember-test-app

This is happening to me too. Fresh app with 0.1.2-beta.1. Maybe something has changed in a dependency upstream?

https://gist.github.com/Soliah/edc8f012cc9e6800005d

[btecu]

Any of you using outputPaths?

#3365

[wstrinz]

I'm getting this too, tried with multiple versions of ember-cli. Not using outputPaths as far as I know, just a plain old ember new myapp.

[mariozig]

@fivetwentysix aside from stopping the server prior to making changes, have you found any sort of work around for this?

I'm experiencing it too in an unadulterated stock ember app on:

version: 0.2.0-beta.1
node: 0.12.0
npm: 2.1.8

@btecu no outputPaths here. Obviously it's referenced in node_modules/ember-cli/lib/broccoli/ember-app.js but the app i just tested on is a fresh install of ember cli, a newed up app, and no modifications other than rewriting a project file out.

[TimothyGu]

See also http://stackoverflow.com/questions/28846170/ember-cli-crash-on-rebuild-after-clean-install-what-am-i-doing-wrong

[btecu]

Probably a bad idea, but what I did to get around this problem was editing app/node_modules/ember-cli/node_modules/symlink-or-copy/copy-dereference/index.js and replace
fs.writeFileSync(dest, contents, { flag: 'wx', mode: srcStats.mode }) with
fs.writeFileSync(dest, contents, { flag: 'w', mode: srcStats.mode })

Restart ember server afterwards...

[bobbyhubbard]

Same issue here. See broccolijs/node-symlink-or-copy#4

[mariozig]

@bobbyhubbard are you sure it's the same bug? nodejs/node-v0.x-archive#8651 says it was fixed in node: 0.12.0 and i'm definitely seeing it with that version.

[stickbyatlas]

Hi folks - an hour ago, I did an npm update in my project directory. Immediately afterward, I started noticing the same crashing behaviour after changing a file while serving. Like others here, I suspect this has to do with an upstream dependency completely breaking everything, but I have no idea which one it could be. Would it be useful to share the contents of package.json here?

(For the record, the 'already existing' file is tmp/class-tmp_cache_dir-85EAruZ0.tmp , which is only relevant in that it's also a tmp/... file. The last step in the trace is Object.fs.symlinkSync. Would be happy to share the rest of the trace if it'll help.)

[fivetwentysix]

This is why npm needs something similar to gemfile.lock

[stickbyatlas]

If I knew how to reverse / undo npm update, I'd do it in a heartbeat. I can't even parse the output of the command, it's just a jumble of different dependency trees and conflict warnings. Every time I think "maybe Javascript has finally matured," something like this happens, the whole building topples, and I yearn for a classic, vetted language with a massive standard library.

[dopin]

I'm getting this too. I'm not sure if this works but if you specify "rimraf":"2.2.8" in package.json, it fixes.
rimraf 2.3.0 is just released about 7 hours ago from now.

Confirming @dopin's suggestion of forcing rimraf to 2.2.8 works. Make sure to add this to dependencies and not devDependencies.

[JohnRodney]

@dopin's suggestion did not work for me. I tried cloning (broken), installing (broken), open old files (worked). Something new in the way that cache files are stored. If I just delete all the cache files with the commonatliy of "caching-writer-dest-dir{otherjunkhere}" then it saved ONCE fine. Next time back to broken.

[fotinakis]

Hitting this too just in the last few hours, yikes yikes...