What causes "Failed to extract tarball" in nikivdev/code?

Delete any cached/partial tarball and re-run `f upgrade` to get a fresh download.

Failed to extract tarball

Error message

Failed to extract tarball

What it means

`extract_release_bundle` (src/upgrade.rs:381+) shells out to the system `tar -xzf` to unpack the downloaded release tarball into a temp dir. If the `tar` process spawns but exits non-zero, the upgrade bails with this message. It is a wrapper around external-tool failure, not a Rust parse error.

Source

Thrown at src/upgrade.rs:396

    Ok(hex::encode(hasher.finalize()))
}

fn extract_release_bundle(tarball: &Path) -> Result<(tempfile::TempDir, PathBuf)> {
    let temp_dir = tempfile::tempdir().context("Failed to create temp directory")?;
    let temp_path = temp_dir.path();

    let status = Command::new("tar")
        .args([
            "-xzf",
            tarball.to_str().unwrap(),
            "-C",
            temp_path.to_str().unwrap(),
        ])
        .status()
        .context("Failed to run tar")?;

    if !status.success() {
        bail!("Failed to extract tarball");
    }

    let bundle_root = fs::read_dir(temp_path)
        .ok()
        .and_then(|mut entries| entries.find_map(|entry| entry.ok().map(|item| item.path())))
        .filter(|path| path.is_dir())
        .unwrap_or_else(|| temp_path.to_path_buf());

    Ok((temp_dir, bundle_root))
}

fn find_bundle_binary(bundle_root: &Path, binary_name: &str) -> Result<PathBuf> {
    let direct = bundle_root.join(binary_name);
    if direct.exists() {
        return Ok(direct);
    }

    let binary_path = fs::read_dir(bundle_root)

View on GitHub (pinned to a747e741ae)

Solutions

Delete any cached/partial tarball and re-run `f upgrade` to get a fresh download.
Verify the archive manually: `tar -tzf <file>` — if it fails, the download is corrupt.
Check sha256 against the release's checksums.txt before extracting.
Ensure a working `tar` supporting gzip is on PATH (`tar --version`); install one if missing.
If GitHub serves an error page instead of the asset, check rate limits / auth token and retry later.

Defensive patterns

Strategy: validation

Validate before calling

# before installing, verify the archive is valid
tar -tzf "$TARBALL" > /dev/null && echo ok || echo "corrupt tarball, re-download"
sha256sum "$TARBALL"  # compare with checksums.txt

Prevention

Verify sha256 against the release checksums.txt before extraction.
Ensure a gzip-capable `tar` is installed in minimal images.
Re-download after any interrupted transfer instead of reusing partial files.
Confirm the downloaded file is gzip (`file <tarball>`), not an HTML error page.

When it happens

Trigger: `tar -xzf <tarball> -C <tmp>` exits non-zero: the tarball is corrupt/truncated (bad download), not gzip, `tar` binary is missing a needed format, or the archive layout is unexpected.

Common situations: Interrupted download leaving a partial file; GitHub asset replaced mid-upgrade; minimal container images shipping bsdtar/GNU tar variants that reject the archive; downloaded an HTML error page saved as the tarball.

Related errors

AI-assisted analysis of nikivdev/code@a747e741ae (2026-09-01). Data as JSON: /api/errors/affa47bda31c3ddb. Report an issue: GitHub.