I’m using ember 1.13.6 with node 0.12.7 and npm 2.13.2 on win32 x64. It happens frequently getting this error by executing “ember server” to launch server:
EPERM, operation not permitted ‘C:\Project\my-app\tmp\core_object-output_path-UnoTIiak.tmp’ other stuff …
I have to terminate program and try again and again to succeed in launching server. When I edit my files and browser get refreshed, it happens again and I need terminate and launch server again. What is this issue?
This problem has reached the point where we might have to abandon ember development on windows. We have tried all the tricks of running as administrator, setting folder permissions, moving the project folder to a location under the users folder - to no avail. We are running Windows 7 64bit.
Here is an example error output:
C:\Work\Projects\Esis\DEV-HTML\Source\Esis.Web.Ember>ember server
version: 1.13.7
Livereload server on http://localhost:49155
Serving on http://localhost:4200/
EPERM, operation not permitted 'C:\Work\Projects\Esis\DEV-HTML\Source\Esis.Web.E
mber\tmp\funnel-output_path-1XW3tUz6.tmp'
Error: EPERM, operation not permitted 'C:\Work\Projects\Esis\DEV-HTML\Source\Esi
s.Web.Ember\tmp\funnel-output_path-1XW3tUz6.tmp'
at Error (native)
at Object.fs.mkdirSync (fs.js:747:18)
at NewStyleTreeWrapper.read (C:\Work\Projects\Esis\DEV-HTML\Source\Esis.Web.
Ember\node_modules\ember-cli\node_modules\broccoli\lib\api_compat.js:24:6)
at C:\Work\Projects\Esis\DEV-HTML\Source\Esis.Web.Ember\node_modules\ember-c
li\node_modules\broccoli\lib\builder.js:98:23
at lib$rsvp$$internal$$tryCatch (C:\Work\Projects\Esis\DEV-HTML\Source\Esis.
Web.Ember\node_modules\ember-cli\node_modules\rsvp\dist\rsvp.js:493:16)
at lib$rsvp$$internal$$invokeCallback (C:\Work\Projects\Esis\DEV-HTML\Source
\Esis.Web.Ember\node_modules\ember-cli\node_modules\rsvp\dist\rsvp.js:505:17)
at C:\Work\Projects\Esis\DEV-HTML\Source\Esis.Web.Ember\node_modules\ember-c
li\node_modules\rsvp\dist\rsvp.js:1001:13
at lib$rsvp$asap$$flush (C:\Work\Projects\Esis\DEV-HTML\Source\Esis.Web.Embe
r\node_modules\ember-cli\node_modules\rsvp\dist\rsvp.js:1198:9)
at process._tickCallback (node.js:355:11)
A colleague of mine is developing on Windows 2012 Server and that seems to be fine so it does seem that the above error is related to running on Windows 7 64 bit somehow.
Note that we’ve excluded the ember project folder from Windows Security Essentials and do not have Windows Search running.
Until a week ago we had 3 PC’s running on windows 7 64 bit. We almost never have errors like this but we have seen them if the npm cache is corrupt. Try npm cache clean first. If that doesn’t fix things, take a look in %APPDATA%\npm-cache, or if you’re using PowerShell, $env:APPDATA\npm-cache. After cleaning the cache, you may still be left with remnants. Manually remove everything in that directory, and try again. Try with ember new dummy first. We don’t run as administrator.
Thank you @broerse. We’ve now tried ‘npm cache clean’ but that still does not solve it for us. For some reason we do not have %AppData%\npm-cache folders - the only npm related folder under %AppData% is the following %AppData%\Roaming\npm but there is no cache folder under that.
Actually this issue seems to be related to Visual Studio and TFS source control over the ember project folder. I can consistently overcome this issue by shutting down VS2015 and it works and then when I restart VS2015 the error is back. Problem is that we do need VS2015 for the server side WebAPI aspect.
As mentioned above this is not an issue with Windows 2012 by the looks of it. We have 3 x development PCs (1 x Win2012 and 2 x Win7) and the issue consistently happens on the Win7 PCs and not on the Win2012 PCs.
I’ve already tried the TFS ignore file (like the Git ignore file) by putting .tfignore file with appropriate entries into the root folder of the ember project, but I’m going to investigate that a bit more.
Interesting. Perhaps there is some port conflict. You can run netstat -a to check it. We have upgraded to Windows 10. Perhaps the fastest way to solve this
The resolution for this was to switch from TFS to GitHub for source control.
I have verified on another machine that that the Windows 10 + TFS combo works just fine, but for some reason the Windows 10 upgrade on my Windows 7 PC fails (probably a topic for a different discussion on a different forum…