Feature/eirikb/windows bootstrap fixes - #304
Merged
Merged
Conversation
Both failures only hit the very first run, since stage1 short-circuits to the cached stage2 afterwards, and both come from the bootstrap inheriting a hostile environment: git bash and pwsh run gg.cmd through cmd.exe, so the batch branch executes with the parent shell's PATH and PSModulePath. stage2.ps1: Get-FileHash lives in a script module, and PowerShell 7 prepends its Core-only copy of Microsoft.PowerShell.Utility to PSModulePath. A child Windows PowerShell then loads that one, keeps the binary cmdlets from the snap-in, and loses the script functions - so Invoke-WebRequest works while Get-FileHash is "not recognized". Hash through .NET instead, which needs no module loading. stage1.bat: bare tar resolves to Git's GNU tar ahead of System32, which shells out to a separate gzip and reads "C:" as a remote host spec. Pin Windows' own bsdtar. A failed unpack also fell through to powershell -file on a stage2.ps1 that was never written, so the real error was buried under a confusing one - check the exit code and that stage2 actually landed. Verified on Windows Server 2022 with cold caches: cmd, pwsh 7, git bash and 32-bit cmd with GNU tar first on PATH all bootstrap, and an unwritable cache dir now reports the unpack failure instead of the PowerShell -file error.
stage1 is what you see when you cat gg.cmd, and every byte ships in it, so the last commit was far too fat there: 1631 -> 2591 bytes for two real fixes. The Sysnative probe goes - SysWOW64 has its own bsdtar, so a 32-bit cmd already resolved a working tar through the plain System32 check and the extra line never did anything. The exit-code guard goes too: we only get here when stage2.ps1 was missing, so checking that it exists afterwards says the same thing in one test and drops GG_UNTAR_ERR with it. Comments cut to the one trap worth naming, since the reasoning lives in the commit log rather than in every copy of gg.cmd. Down to 1945 bytes, +314 over the original instead of +960. Re-verified on Windows Server 2022 with cold caches: cmd, pwsh 7, git bash, and 32-bit cmd with GNU tar first on PATH, plus an unwritable cache dir still reporting the failure.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Both failures only hit the very first run, since stage1 short-circuits to the cached stage2 afterwards, and both come from the bootstrap inheriting a hostile environment: git bash and pwsh run gg.cmd through cmd.exe, so the batch branch executes with the parent shell's PATH and PSModulePath.
stage2.ps1: Get-FileHash lives in a script module, and PowerShell 7 prepends its Core-only copy of Microsoft.PowerShell.Utility to PSModulePath. A child Windows PowerShell then loads that one, keeps the binary cmdlets from the snap-in, and loses the script functions - so Invoke-WebRequest works while Get-FileHash is "not recognized". Hash through .NET instead, which needs no module loading.
stage1.bat: bare tar resolves to Git's GNU tar ahead of System32, which shells out to a separate gzip and reads "C:" as a remote host spec. Pin Windows' own bsdtar. A failed unpack also fell through to powershell -file on a stage2.ps1 that was never written, so the real error was buried under a confusing one - check the exit code and that stage2 actually landed.
Verified on Windows Server 2022 with cold caches: cmd, pwsh 7, git bash and 32-bit cmd with GNU tar first on PATH all bootstrap, and an unwritable cache dir now reports the unpack failure instead of the PowerShell -file error.