Repository navigation
fix: self-update extracts the binary, not its directory - #64
Merged
animeshchaudhri merged 1 commit intoOct 21, 2026
Merged
animeshchaudhri merged 1 commit into
animeshchaudhri merged 1 commit into
Conversation
The Linux release tarball is packed with `tar czf ... -C dist rustman`, so its first member is the directory entry `rustman/`. extract_binary took the first entry whose file name is `rustman`, and a directory's path `rustman/` has that file name too, so it wrote out the directory as an empty file and verify_binary failed with "extracted binary is too small". Every in-app update on Linux failed this way; while the -nokit tarball existed it was hidden, because its directory is `rustman-nokit/` and builds picked it first. extract_binary now takes regular files only. Tests build the Linux and macOS tarball layouts and extract them.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
In-app updates on Linux fail with "extracted binary is too small" whenever the update is the standard Linux tarball, which since v0.3.12-dev.47 packs the binary inside a directory. v0.3.15-dev.51 ships only that tarball, so every Linux update to it fails.
The Linux release tarball is packed with
tar czf rustman-linux-<arch>.tar.gz -C dist rustman, so its first member is the directory entryrustman/.extract_binarytakes the first entry whose file name isrustman, andPath::new("rustman/").file_name()isrustmantoo, so it writes the directory out as an empty file andverify_binaryrejects it. While the -nokit tarball existed this was hidden: its directory isrustman-nokit/, and the asset picker chose it first (the mix-up fixed for #62).extract_binarynow takes regular files only (entry.header().entry_type().is_file()).Testing
rustman-linux-x86_64.tar.gzof v0.3.15-dev.51 throughextract_binaryandverify_binary: on masterErr("extracted binary is too small")with 0 bytes written; with this changeOk, 23,450,952 bytes, the sizetar tvlists forrustman/rustman.extracts_the_binary_from_the_linux_tarball_layoutandextracts_the_binary_from_the_macos_tarball_layoutbuild those two layouts withtar::Builder(a directory entry first, as GNU tar writes it, and a single file at the root) and extract them. Without the check the Linux one fails with an empty file and the macOS one passes, as on master.cargo test --bins: 141 passed and 3 ignored; with--no-default-features131 and 3.cargo check --all-targets --target x86_64-pc-windows-gnupasses with master's one warning. rustfmt and clippy are clean on the change.Not tested on macOS or Windows. The macOS tarball holds the binary at its root, the layout the second test covers; Windows goes through the zip path, which this change does not touch.