Windows Symlink / Windows Creators edition

[MrChriZ]

---

Output from ember version --verbose && npm --version && yarn --version:

ember-cli: 2.13.2
http_parser: 2.7.0
node: 6.9.4
v8: 5.1.281.89
uv: 1.9.1
zlib: 1.2.8
ares: 1.10.1-DEV
icu: 57.1
modules: 48
openssl: 1.0.2j
os: win32 x64
3.10.10
0.19.1

When I run Ember serve I'm greeted with the message 'Running without permission to symlink will degrade build performance.'

I'm running Windows 10 Creators Update with Developer mode enabled. According to this: https://blogs.windows.com/buildingapps/2016/12/02/symlinks-windows-10/#i4JApqmBvvKL4eT4.97 I shouldn't need to run in admin mode any more with developer mode enabled.

If I run in admin mode the warning goes away. Is this issue with Ember or is that blog entry incorrect?

[stefanpenner]

I did test this with the earliest release and symlinking stuff seemed to work really well. I can't remember if the warning happened or not...

[stefanpenner]

My guess is the warning needs to be fixed.

[stefanpenner]

https://github.com/ember-cli/ember-cli/blob/2afca8eee9393026b5af6ec02157b7c53cb67feb/lib/utilities/windows-admin.js#L88

[CrshOverride]

What's interesting is that symlinkOrCopy.canSymlink seems to be returning false as well. I would expect that value to be true as it uses Node's fs.symlinkSync internally and should only throw if there was an error symlinking.

Aside from NET SESSION, the only test for Developer Mode seems to be reading a registry key. It's possible, but ugly.

[Bouke]

Update:

After some more troubleshooting I found that there was another issue at play here. While having Visual Studio 2017 open containing that same project, Visual Studio would keep a handle to the files inside tmp/. This was found using the handle program. When Visual Studio is not open, creation of the symlinks and building in general works.

The output of ember-cli however mentions that symlinks cannot be created, but this warning is not correct. When using the fix proposed for symlink-or-copy, symlinks can be created just fine. So for now, I've specified that pull request as a dependency and symlinks are created just fine, despite the warning from ember-cli.

---

Old post:

Currently the creation of symlinks is failing on Windows with Developer Mode enabled.

>ember build ...
  Build failed.
  Build Error (Funnel)

  EPERM: operation not permitted, symlink 'XXX\app' -> 'XXX\tmp\funnel-input_base_path-YqiFIS7v.tmp'

Developer mode is enabled, symlinks can be created without elevation:

>net session
System error 5 has occurred.

Access is denied.
>mklink /d tmp\app ..\app
symbolic link created for tmp\app <<===>> ..\app

>dir tmp
13/02/2018  20:37    <SYMLINKD>     app [..\app]

I suspect this is because the necessary flag isn't being passed to CreateSymbolicLink. However I must admit not having much further insights into symlinks on the Windows OS.

Symlinks are created either using the mklink command or the CreateSymbolicLink API

• mklink There is no change in how to call mklink. For users who have Developer Mode enabled, the mklink command will now successfully create a symlink if the user is not running as an administrator.
• CreateSymbolicLink To enable the new behavior when using the CreateSymbolicLink API, there is an additional dwFlags option you will need to set: (...)

source

[jacobq]

Not sure if this is the same issue, but I started running into this today on a Windows 10 computer that "used to work a couple months ago" (presumably before I ran git pull on my project and updated something). In my case the output looks like this (adding for SEO/visibility):

Build Error (WaitForTrees)

EPERM: operation not permitted, symlink '<project root>\node_modules\@ember\edition-utils' -> '%TEMP%\embroider\bbac7b\node_modules\ember-cli-htmlbars\node_modules\@ember\edition-utils'

I was using Git Bash (MINGW64), but it also happens in cmd.exe. In .git/config I had [core] ... symlinks = false. (Setting it to true had no positive effect, just caused git fetch to start also outputting error: daemon terminated) I also recently updated from nvm-windows 1.1.7 to 1.1.9 and was using Node 18.2.0, but I also tried with 16.15.0 and had the same problem.

Note: Running CLI as elevated user (admin) circumvents the problem.