`porter archive` fails on windows
Closed this issue · 8 comments
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
I have a windows laptop, so could possibly help debug this one if required?
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?
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
Ah perfect, that lines up with what I was seeing when attempting to debug. @jarnfast you got here first, did you want this one?
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 😸
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 :)
@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.
@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 :)