mirror of
https://github.com/affaan-m/ECC.git
synced 2026-10-14 12:15:29 +02:00
montjeffrey
bfd4f8255a
materializeTree passed the archive as an absolute path. GNU tar, which Git for Windows bundles and puts first on PATH in Git Bash, reads an -f argument containing a colon as a host:path remote spec and fails with "Cannot connect to C: resolve failed". bsdtar, the tar in system32 that PowerShell resolves, has no remote-spec parsing, so the fault only appeared under a bash-based shell - and there it failed a committed test, not just a dry run. Name the archive relatively and run tar with dest as its cwd, which extracts identically under both tars and makes -C unnecessary. git archive keeps the absolute -o path, which git handles on Windows. Two tests, because the environment-dependent kind of fault needs both: one injects a spawn and asserts no tar argument is absolute or drive-lettered, which holds the invariant on any platform; the other prepends Git's bundled GNU tar to PATH and extracts into a drive-letter destination, so the original failure is reproducible from PowerShell too, where it was previously invisible.