chenhg5/cc-connect · error

get executable path: %w

Error message

get executable path: %w

What it means

replaceBinary starts by locating the running executable with os.Executable(); if the OS refuses (process image unavailable, exec path deleted mid-run, unsupported environment), the error is wrapped as "get executable path: %w". Without the path, self-update cannot proceed safely.

Source

Thrown at core/updater.go:248

	}
	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)
		}
	}
	return nil, fmt.Errorf("cc-connect binary not found in zip archive")
}

func replaceBinary(newBinary []byte) error {
	execPath, err := os.Executable()
	if err != nil {
		return fmt.Errorf("get executable path: %w", err)
	}
	execPath, err = filepath.EvalSymlinks(execPath)
	if err != nil {
		return fmt.Errorf("resolve symlinks: %w", err)
	}

	dir := filepath.Dir(execPath)
	tmpFile, err := os.CreateTemp(dir, "cc-connect-update-*")
	if err != nil {
		return fmt.Errorf("create temp file: %w", err)
	}
	tmpPath := tmpFile.Name()

	if _, err := tmpFile.Write(newBinary); err != nil {
		tmpFile.Close()
		os.Remove(tmpPath)
		return fmt.Errorf("write new binary: %w", err)
	}

View on GitHub (pinned to 4000b2338a)

Solutions

  1. Restart cc-connect from an intact binary path so os.Executable() resolves again — update the freshly installed binary instead.
  2. Check that /proc is mounted if running in a container (mount -t proc proc /proc).
  3. Reinstall the binary to its expected location, then run the update from there.
  4. If you manage deployment externally (package manager), update via that mechanism instead of the in-process self-updater.
  5. If this reproduces on a supported platform with the file present, file a bug with the wrapped errno (the %w cause shows the underlying OS error).

Example fix

# before: binary removed under a running daemon
rm /usr/local/bin/cc-connect  # daemon still running
# after: reinstall, restart, then update
sudo cp ./cc-connect-new /usr/local/bin/cc-connect && sudo systemctl restart cc-connect
Defensive patterns

Strategy: try-catch

Validate before calling

p, err := os.Executable()
if err != nil {
    return fmt.Errorf("cannot self-update: %v", err)
}
if _, err := os.Stat(p); err != nil {
    return fmt.Errorf("running binary missing: %v", err)
}

Try / catch

if err := selfUpdate(); err != nil {
    if strings.Contains(err.Error(), "get executable path") {
        // fall back to a full reinstall / restart from a valid binary
    }
}

Prevention

When it happens

Trigger: SelfUpdate -> replaceBinary ran while os.Executable() returned an error: the binary file was deleted/renamed while the process ran, the executable was started via a mechanism that doesn't provide /proc/self/exe-style info, memory pressure in syscalls on exotic platforms.

Common situations: User deleted the old binary after starting cc-connect (e.g. cleaned install dir while daemon running); running from a tmpfs cleared at runtime; cross-compiling/embedding scenarios where the runtime lacks procfs (some containers with masked /proc).

Understand the failure class

Background: "File not found" and ENOENT errors: why libraries can't find a file that should exist — this error's family across 50 libraries.

Related errors


AI-assisted analysis of chenhg5/cc-connect@4000b2338a (2026-09-06). Data as JSON: /api/errors/eb383da59122268b. Report an issue: GitHub.