Describe the bug

There is a bug with go-containerregistry when running on windows: When pulling images with duplicate (although empty) layers, and because the writing of the layers are concurrent, this os.Rename sometimes fails intermittently with status ACCESS_DENIED if the go routines have a bad interleaving. This problem does not occur on linux.

I have confirmed locally that writing the layers sequentially instead of concurrently indeed fixes the error. I am tracking this issue in Porter getporter/porter#2917

To Reproduce

On windows, run crane pull --format oci on an image with duplicate layers, for example
crane pull --format oci ghcr.io/getporter/examples/whalegap@sha256:8b92b7269f59e3ed824e811a1ff1ee64f0d44c0218efefada57a4bebc2d7ef6f output
The error only occurs sometimes, so you might need to rerun it a couple of times. Eventually you'll get an Access Denied error:

PS C:\Users\lliljenberg\dev\tars> crane pull --format oci ghcr.io/getporter/examples/whalegap@sha256:8b92b7269f59e3ed824e811a1ff1ee64f0d44c0218efefada57a4bebc2d7ef6f hello3
Error: error writing layer: rename hello3\blobs\sha256\a3ed95caeb02ffe68cdd9fd84406680ae93d633cb16422d00e8a7c22955b46d42723601231 hello3\blobs\sha256\a3ed95caeb02ffe68cdd9fd84406680ae93d633cb16422d00e8a7c22955b46d4: Access is denied.

Note: the ghcr website doesn't show the duplicate layers, but if you do crane manifest ghcr.io/getporter/examples/whalegap@sha256:8b92b7269f59e3ed824e811a1ff1ee64f0d44c0218efefada57a4bebc2d7ef6f you'll see the layer whose digest is sha256:a3ed95.... appear 3 times.

Expected behavior

There should be no intermittent errors. I believe empty layers are a common in images when a dockerfile statement peforms some action that doesn't affect the filesystem.

Additional context

This was previously raised in #1794 but abandoned.

• Version of the module: commit 051d642
• Registry used (e.g., GCR, ECR, Quay) GHCR