-
Notifications
You must be signed in to change notification settings - Fork 245
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
Windows: Rename operation throwing exception #3751
Comments
My whole team who is on windows is getting this error all at once since we upgraded our CDK stack and CLI version to 2.40, so it seems to be quite consistently happen for everyone on windows. This is a huge blocker for the team the past week as everyone is experiencing this. Please urgently address as this is a big bug that should not have gotten released after testing |
Our testing (including Windows) worked flawlessly... The issue here is that we are unable to reproduce the issue with the problematic A/V software configurations due to various reasons (licenses, policies, etc...). I see even setting |
Windows does not allow renaming files that are currently open, or directories that contain open files. When antivirus software is used, files are open for analysis by the A/V software, making it impossible to rename files too quickly after they've been created. This was already reported in #992 and addressed, however the issue was re-introduced in #3724, in which tarballs were extracted into temporary directories that were then renamed. Changed the code back to a form taht extracts files directly into their final place instead of staging via a temporary space, and added comments warning maintainers about the specific issue being solved here, so that hopefully the problem does not get re-introduced again in the future. Fixes #3751
Windows does not allow renaming files that are currently open, or directories that contain open files. When antivirus software is used, files are open for analysis by the A/V software, making it impossible to rename files too quickly after they've been created. This was already reported in #992 and addressed, however the issue was re-introduced in #3724, in which tarballs were extracted into temporary directories that were then renamed. Changed the code back to a form taht extracts files directly into their final place instead of staging via a temporary space, and added comments warning maintainers about the specific issue being solved here, so that hopefully the problem does not get re-introduced again in the future. Fixes #3751 --- 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
|
The fix is in and I will try to release a fixed version of the jsii runtimes tomorrow morning. If you need un-blocked faster or want to early-test to make sure the issue is fixed, you can download this release-package.zip (version You can verify your download by using the following signature (my public keys are registered on GitHub and also keybase.io):
|
Thank you for the fix @RomainMuller, I just tested it successfully. |
Thank you for confirming! I'll kick off the release for 1.96.0 right now... |
Describe the bug
With JSII 1.67.0 the bug from #992 resurfaces again, the rename operation is throwing an exception.
Expected Behavior
JSII should run without errors
Current Behavior
Reproduction Steps
Run any cdk command, e.g.
cdk diff
in a cdk project on Windows with A/V software enabled.Possible Solution
The bug might have been introduced by #3724. Here, the fix from #992 is no longer present and the files are copied again, instead of being extracted directly to the target.
Additional Information/Context
The issue is not present in 1.66.0
SDK version used
1.67.0
Environment details (OS name and version, etc.)
Windows 10
The text was updated successfully, but these errors were encountered: