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
- Restart cc-connect from an intact binary path so os.Executable() resolves again — update the freshly installed binary instead.
- Check that /proc is mounted if running in a container (mount -t proc proc /proc).
- Reinstall the binary to its expected location, then run the update from there.
- If you manage deployment externally (package manager), update via that mechanism instead of the in-process self-updater.
- 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
- Never delete the running binary; replace it atomically via rename
- Restart the daemon before wiping install directories
- Run in environments with /proc mounted
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.