porter archive fails on windows

[ludfjig]

Describe the bug

porter archive fails intermittently on windows. This is due to a race condition in go-containerregistry.

To Reproduce

Run
porter archive name.tgz -r ghcr.io/getporter/examples/whalegap:v0.2.0 on windows (on my branch, otherwise you'll get an error that has been fixed since, but not yet merged).
You'll notice that about 50% of the time, you'll get an error such as this one

error preparing bundle artifact: error writing layer: rename C:\Users\LLILJE~1\AppData\Local\Temp\examples-whalegap-0.2.0827645715\artifacts\layout\blobs\sha256\a3ed95caeb02ffe68cdd9fd84406680ae93d633cb16422d00e8a7c22955b46d4706634942 C:\Users\LLILJE~1\AppData\Local\Temp\examples-whalegap-0.2.0827645715\artifacts\layout\blobs\sha256\a3ed95caeb02ffe68cdd9fd84406680ae93d633cb16422d00e8a7c22955b46d4: Access is denied.
error preparing bundle artifact: error writing layer: rename C:\Users\LLILJE~1\AppData\Local\Temp\examples-whalegap-0.2.0827645715\artifacts\layout\blobs\sha256\a3ed95caeb02ffe68cdd9fd84406680ae93d633cb16422d00e8a7c22955b46d4706634942 C:\Users\LLILJE~1\AppData\Local\Temp\examples-whalegap-0.2.0827645715\artifacts\layout\blobs\sha256\a3ed95caeb02ffe68cdd9fd84406680ae93d633cb16422d00e8a7c22955b46d4: Access is denied.

With the example bundle, the offending file is always the one starting with "a3....".

The error comes from an os.Rename which fails with ERROR_ACCESS_DENIED. On windows, you can only rename a file that is not opened by any other process. I have used handle.exe to confirm that the file handle isn't open by another process (I think).

 

Expected behavior

The command should work 100% of the time.

Version

My windows branch https://github.com/ludfjig/porter/tree/win_integrationtest

[dgannon991]

I have a windows laptop, so could possibly help debug this one if required?

[jarnfast]

Originally referenced branch seems to have been merged into main.
Reproduced the error with a 40% failure rate on the whalegap bundle using porter 1.0.17 - other bundles archives without issues.

Could the problem be a race condition with a virus scanner having the file open?

[ludfjig]

I believe the issue is a race condition in go-container registry. I reported it here google/go-containerregistry#1794 and made a prototype PR google/go-containerregistry#1802. I don't have time to work on this, so feel free to pick this up

[dgannon991]

Ah perfect, that lines up with what I was seeing when attempting to debug. @jarnfast you got here first, did you want this one?

[jarnfast]

Ah perfect, that lines up with what I was seeing when attempting to debug. @jarnfast you got here first, did you want this one?

@dgannon991 no, I don't feel brave enough to venture into fixing go-containerregistry 😨 😉 (or at least lacking the time to do so)

I initially thought it would be an easy fix as I'm archiving bundles on windows all the time without any issues - apparently I don't have many empty layers 😸

[dgannon991]

No worries, just wanted to make sure I wasn't stepping on your toes :) I've raised an issue and then put in this PR which does successfully address the issue. Both are almost entirely copy/pasted from the issue and PR @ludfjig first submitted, so now I'll just jump through google's hoop and hopefully we'll get somewhere :)

[kichristensen]

@dgannon991 Just noticed that the PR in go-containerregistry was merged, thanks for getting it through. Hopefully the next verison of go-containerregistry it will be release soon, so this bug can be fixed.

[dgannon991]

@kichristensen - yes, Sarah pulled some strings and got it through. Sadly their release cycle isn't too frequent, but hopefully there will be one soon and we can move towards it :)