fix(kernel): error raised during rename operation on win32

[RomainMuller]

When loading a new library into the jsii kernel, the provided tarball
was extracted to a temporary directory, then moved into it's final
location. On Windows, this operation could fail on an EACCESS or
EPERM error (often due to malware scanners accessing the file for
inspection on file systems which do not support renaming files that are
being accessed).

This changes how the load API works so taht the tarball is extracted
directly in it's final install location, so that no rename operation is
needed.

Fixes #992

---

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[RomainMuller]

Note: the change appears much bigger than it really is because it involves changing the indentation of a large chunk of code (no longer wrapped under a try { ... } finally { ... } block). You'll get a much better view on the actual change if you hide whitespace changes.

[aws-cdk-automation]

AWS CodeBuild CI Report

• CodeBuild project: AutoBuildProject6AEA49D1-Blkkw9bQFn8A
• Commit ID: 000b3cd
• Result: SUCCEEDED
• Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

[rix0rrr]

Guess I'm not necessarily opposed to this, but generally we do moves for a reason: to preserve atomicity.

Can you elaborate why this would not be an issue in this case? Why did we do the move in the first place?

[rix0rrr]

Okay talked to Elad, it's not for atomicity reasons. Kay then.

[RomainMuller]

Guess I'm not necessarily opposed to this, but generally we do moves for a reason: to preserve atomicity.

Can you elaborate why this would not be an issue in this case? Why did we do the move in the first place?

So the move was quite probably due to the fact the contents of the tarball is nested under an undesirable package directory, while we need to install into node_modules/<package-name> instead. Either the strip feature was unavailable (or undocumented) at the time we first wrote this, or it didn't occur to us we could use it.

But yeah it's not for atomicity since we should be able to assume only ONE thread is running through there at a time (node being collaborative multitasking only)

[mergify]

Thank you for contributing! ❤️ I will now look into making sure the PR is up-to-date, then proceed to try and merge it!

[mergify]

Merging (with squash)...

[rix0rrr]

assume

Just going to leave this right here 😛

But yeah, let's try it, probably worth the risk.

[aws-cdk-automation]

AWS CodeBuild CI Report

• CodeBuild project: AutoBuildProject6AEA49D1-Blkkw9bQFn8A
• Commit ID: 6fa2b8f
• Result: SUCCEEDED
• Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

[mergify]

Merging (with squash)...