-
Notifications
You must be signed in to change notification settings - Fork 246
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
New feature from PR #4181 causes "EPERM: operation not permitted, symlink" on Windows #4208
Comments
I am having the same issue on Windows 11. I found a workaround for now in #4207 by setting the environment variable JSII_RUNTIME_PACKAGE_CACHE to "disabled". You can test if that works by setting the variable in Powershell
Afterwards you can set it as a user environment variable, so you don't have to set it all the time. |
Setting |
I've also been affected by this, and setting JSII_RUNTIME_PACKAGE_CACHE="disabled" resolved the issue for me. |
In #4181, a faster method to load modules was introduced: symlinking instead of recursing through the directory tree, mostly affecting the load times of large modules. Since Windows Vista, non-Administrator users on Windows aren't allowed to create symlinks anymore, so this new loading method fails for users working in corporate Windows environments. Catch the error and fall back to the slower copying method if that happens. Fixes #4208.
In #4181, a faster method to load modules was introduced: symlinking instead of recursing through the directory tree, mostly affecting the load times of large modules. Since Windows Vista, non-Administrator users on Windows aren't allowed to create symlinks anymore, so this new loading method fails for users working in corporate Windows environments. Catch the error and fall back to the slower copying method if that happens. Fixes #4208. --- By submitting this pull request, I confirm that my contribution is made under the terms of the [Apache 2.0 license]. [Apache 2.0 license]: https://www.apache.org/licenses/LICENSE-2.0
|
Describe the bug
The changes to
link.ts
introduced in #4181 render the CDK unusable on my Windows installation. This problem could affect many Windows users.Windows blocks the creation of symlinks for non-administrative users by default.
Expected Behavior
The CDK should successfully complete common operations such as
cdk ls
.Current Behavior
The CDK crashes with the following error message, caused by a default Windows policy that blocks the creation of symlinks for non-administrative users.
Reproduction Steps
cdk init sample-app --language java
maven package
orcdk ls
. Maven must be installed.I suspect that other languages are affected as well, so you might be able to reproduce this with any other language.
Possible Solution
The Windows Developer Mode disables the policy and allows the creation of the symlinks: https://learn.microsoft.com/en-gb/windows/apps/get-started/enable-your-device-for-development
Developer mode disables several other safeguards and allows i.e. the installation of untrusted apps, so it should be avoided if not strictly needed.
There are a few potentially better options:
Additional Information/Context
No response
SDK version used
versions that contain PR #4181, e.g. jsii 1.86.1
Environment details (OS name and version, etc.)
Windows 11 Pro 22621.1992
The text was updated successfully, but these errors were encountered: