ggcr: WriteImage race condition on Windows

[ludfjig]

Describe the bug

Context: Porter uses go-containerregistry, and I am making an effort to better support Porter on Windows.

I have ran into 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 here

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.
PS C:\Users\lliljenberg\dev\tars>

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

• Version of the module
• Registry used (e.g., GCR, ECR, Quay)

[ludfjig]

I wouldn't mind doing a pr for this, just unsure what the best way to fix it. I could check for windows GOOS at runtime, and in that case run write the image sequentially. Thoughts?

[github-actions]

This issue is stale because it has been open for 90 days with no
activity. It will automatically close after 30 more days of
inactivity. Keep fresh with the 'lifecycle/frozen' label.