chenhg5/cc-connect · error
cc-connect binary not found in archive
Error message
cc-connect binary not found in archive
What it means
extractBinaryFromTarGz walks every header in the downloaded tar.gz and returns this error when no regular file whose basename starts with "cc-connect" is found. It means the archive downloaded fine but does not contain the expected binary entry.
Source
Thrown at core/updater.go:223
return nil, err
}
defer gr.Close()
tr := tar.NewReader(gr)
for {
hdr, err := tr.Next()
if err == io.EOF {
break
}
if err != nil {
return nil, err
}
name := filepath.Base(hdr.Name)
if strings.HasPrefix(name, "cc-connect") && hdr.Typeflag == tar.TypeReg {
return io.ReadAll(tr)
}
}
return nil, fmt.Errorf("cc-connect binary not found in archive")
}
func extractBinaryFromZip(data []byte) ([]byte, error) {
r, err := zip.NewReader(bytes.NewReader(data), int64(len(data)))
if err != nil {
return nil, err
}
for _, f := range r.File {
name := filepath.Base(f.Name)
if strings.HasPrefix(name, "cc-connect") && !f.FileInfo().IsDir() {
rc, err := f.Open()
if err != nil {
return nil, err
}
defer rc.Close()
return io.ReadAll(rc)
}
}View on GitHub (pinned to 4000b2338a)
Solutions
- Download the archive and run `tar -tzf <archive>` to list entries; confirm a regular file whose basename starts with cc-connect exists.
- Fix the release asset so it contains a regular (not symlink) file named cc-connect* (or the platform-suffixed name still starting with cc-connect).
- Update the updater's extraction match if the official binary was renamed — the check is prefix + tar.TypeReg only.
- If your mirror wraps the binary in a top-level folder, that is fine (filepath.Base is used) — the problem is the final basename, so rename the file inside the archive.
- As a workaround, extract manually and replace the binary in place, then restart.
Example fix
// release CI: before mv cc-connect-agent ccagent && tar czf cc-connect.tar.gz ccagent // after tar czf cc-connect.tar.gz cc-connect
Defensive patterns
Strategy: validation
Validate before calling
out, _ := exec.Command("tar", "-tzf", archivePath).Output()
if !strings.Contains(string(out), "cc-connect") {
return fmt.Errorf("archive lacks cc-connect binary: %s", out)
} Prevention
- Verify release asset contents in CI with tar -tzf before publishing
- Keep the binary basename prefixed with cc-connect in all packaging scripts
- Smoke-test the self-update path in a staging release
When it happens
Trigger: SelfUpdate downloaded a tar.gz whose entries do not include a regular file named cc-connect* (basename match, tar.TypeReg): wrong artifact downloaded (source archive, checksums-only archive), asset renamed to e.g. ccon/agent binary, binary nested under a name not starting with cc-connect, or a symlink-only entry (Typeflag != TypeReg).
Common situations: Release process changed the binary name inside the archive; user mirrored/renamed assets; platform asset mismatch (macOS .zip downloaded but routed to tar.gz extraction); archive contains directory entries only because upload flattened wrongly.
Understand the failure class
Background: 'Could not be found', 'does not exist', 'not found in database': the resource-not-found family when an ID, slug, key, or URI lookup comes back empty — this error's family across 20 libraries.
Related errors
AI-assisted analysis of chenhg5/cc-connect@4000b2338a (2026-09-06).
Data as JSON: /api/errors/126c29c23d234684.
Report an issue: GitHub.