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

  1. Download the archive and run `tar -tzf <archive>` to list entries; confirm a regular file whose basename starts with cc-connect exists.
  2. 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).
  3. Update the updater's extraction match if the official binary was renamed — the check is prefix + tar.TypeReg only.
  4. 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.
  5. 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

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.