Stop handing tar a path it may read as a remote host - #6
Merged
Conversation
Creating a workspace on Windows failed partway through and rolled back, taking roughly twenty-five seconds to do it — long enough that the pods appeared, started, and were then killed, which reads as a timeout rather than a failure. The cause was the source snapshot: `tar -cf C:\...\source.tar` is a request to GNU tar to connect to a host named "C", and it answers "Cannot connect to C: resolve failed". Which tar answers is decided by PATH order. Windows ships bsdtar in System32, which takes the path literally and works; Git for Windows ships GNU tar, which does not, and Git for Windows usually comes first. The same command therefore succeeded or failed depending on what else was installed — and every provider snapshots the same way, so this was never specific to Kubernetes. `--force-local` would fix GNU tar and break bsdtar, which rejects the option, so the archive is now written through stdout and no path is passed to tar at all. Nothing has to detect a flavour, and nothing has to be revisited for the next tool that takes a path. Verified on Windows against a live cluster: creation with GNU tar first on PATH failed after 25 seconds before this change and completes in 78 seconds after it. Two long-standing Windows test failures in the snapshot suite were the same bug and now pass.
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
2 participants
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.
Problem
Creating a workspace on Windows failed partway through and rolled back after ~25 seconds — long enough that pods appeared, started, and were then killed, which presents as a timeout rather than a failure.
The source snapshot runs:
To GNU tar,
C:\...ishost:path— a request to connect to a host namedC:Which tar answers is decided by PATH order. Windows ships bsdtar in
System32, which takes the path literally and works. Git for Windows ships GNU tar, which does not — and Git for Windows usually comes first. The same command succeeded or failed depending on what else was installed.Every provider snapshots through this path, so this was never specific to Kubernetes.
Change
--force-localwould fix GNU tar and break bsdtar, which rejects the option. Instead the archive is written through stdout, so no path is passed to tar at all:Nothing detects a flavour, and nothing has to be revisited for the next tool that takes a path.
runToFilecarries the same timeout, kill and error semantics asrun, and resolves only after the file is closed so a caller may read it immediately.Validation
Windows, against a live kind cluster, with GNU tar first on PATH:
Two long-standing Windows failures in the snapshot suite — hard-linked files, and mutation-during-archive detection — were this same bug, and now pass. The remaining Windows failures (symlinks, POSIX modes) are unrelated and unchanged.