wai-quantum-desktop 0.1.1: an app on an external drive updates itself, and one on a disk image does not #580

Merged

dcharlot merged 1 commit from wai/quantum-desktop-0.1.1-b into main 2026-11-02 18:27:38 -05:00

Conversation 0 Commits 1 Files changed 6 +64 -22

dcharlot commented 2026-11-02 13:07:31 -05:00

Owner

Copy link

Replaces #577 and #573: the same change on current main, on top of #574, which moved the desktop's updater to 2.14.1 and zip to 9.2.2. Both earlier PRs conflicted only in the changelog, and #577 had passed all 20 checks; the entry now sits beside the zip note, away from the top where every PR inserts.

The macOS app decided it was on its disk image by whether its path began with /Volumes. That is wrong in both directions, and this makes it ask the volume instead. The release of 0.1.0 found it: the runner's working folder is on an external drive, so the Apple silicon build failed its own update-status check.

Where the app runs	Before	Now
An external drive, /Volumes/Scratch/…	"runs from its disk image"; never updates	updates itself
A disk image mounted outside /Volumes	"updates_itself":true, and could not	says why not
A copy Gatekeeper translocated (read-only)	"updates_itself":true, and could not	says why not
/Applications	updates itself	updates itself

What changes

• on_read_only_volume: the volume's read-only flag (statvfs, through rustix's safe call), on macOS. installed_by and updates_itself take the answer, so their tests state each case.
• A test on a real read-only volume and a writable one, on macOS, and wai-quantum-studio.yml holds that it ran.
• Version 0.1.1, in Cargo.toml, tauri.conf.json and the lockfile. The tag wai-quantum-desktop-v0.1.0 and its release stay as they are; nothing points to them, and 0.1.1 is the first version with installers for every platform.
• rustix was already in the lockfile, at the same version.

Checked

• On a real disk image: the released 0.1.0 x86_64 image, mounted read-only outside /Volumes on an Apple silicon Mac. The volume's flag reads read-only for the app inside it, and writable for an ordinary file. The 0.1.0 build run from there under Rosetta says "updates_itself":true, the bug in the second row.
• macOS build host, on this branch: cargo tree -i zip gives zip 9.2.2 through tauri-plugin-updater 2.14.1. cargo test --locked --release, 20 passed, including a_read_only_volume_is_told_from_a_writable_one, only_a_copy_installed_by_its_own_installer_updates_itself and an_update_is_held_to_this_build_s_key_and_the_version_it_was_signed_for. cargo clippy --locked --release --all-targets -- -D warnings is clean.
• Not run here: the 0.1.1 build on a mounted disk image, or a translocated copy. Those rows rest on the flag above. The next release's check runs the bundled app on the runner's external drive, which is the first row.
• The public-name check is clean.

🤖 Generated with Claude Code

Replaces #577 and #573: the same change on current main, on top of #574, which moved the desktop's updater to 2.14.1 and `zip` to 9.2.2. Both earlier PRs conflicted only in the changelog, and #577 had passed all 20 checks; the entry now sits beside the `zip` note, away from the top where every PR inserts. The macOS app decided it was on its disk image by whether its path began with `/Volumes`. That is wrong in both directions, and this makes it ask the volume instead. The release of 0.1.0 found it: the runner's working folder is on an external drive, so the Apple silicon build failed its own `update-status` check. | Where the app runs | Before | Now | |---|---|---| | An external drive, `/Volumes/Scratch/…` | "runs from its disk image"; never updates | updates itself | | A disk image mounted outside `/Volumes` | `"updates_itself":true`, and could not | says why not | | A copy Gatekeeper translocated (read-only) | `"updates_itself":true`, and could not | says why not | | `/Applications` | updates itself | updates itself | ## What changes - `on_read_only_volume`: the volume's read-only flag (`statvfs`, through `rustix`'s safe call), on macOS. `installed_by` and `updates_itself` take the answer, so their tests state each case. - A test on a real read-only volume and a writable one, on macOS, and `wai-quantum-studio.yml` holds that it ran. - Version 0.1.1, in `Cargo.toml`, `tauri.conf.json` and the lockfile. The tag `wai-quantum-desktop-v0.1.0` and its release stay as they are; nothing points to them, and 0.1.1 is the first version with installers for every platform. - `rustix` was already in the lockfile, at the same version. ## Checked - **On a real disk image:** the released 0.1.0 x86_64 image, mounted read-only outside `/Volumes` on an Apple silicon Mac. The volume's flag reads read-only for the app inside it, and writable for an ordinary file. The 0.1.0 build run from there under Rosetta says `"updates_itself":true`, the bug in the second row. - **macOS build host, on this branch:** `cargo tree -i zip` gives `zip` 9.2.2 through `tauri-plugin-updater` 2.14.1. `cargo test --locked --release`, 20 passed, including `a_read_only_volume_is_told_from_a_writable_one`, `only_a_copy_installed_by_its_own_installer_updates_itself` and `an_update_is_held_to_this_build_s_key_and_the_version_it_was_signed_for`. `cargo clippy --locked --release --all-targets -- -D warnings` is clean. - **Not run here:** the 0.1.1 build on a mounted disk image, or a translocated copy. Those rows rest on the flag above. The next release's check runs the bundled app on the runner's external drive, which is the first row. - The public-name check is clean. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

dcharlot added 1 commit 2026-11-02 13:07:31 -05:00

wai-quantum-desktop 0.1.1: an app on an external drive updates itself, and one on a disk image does not ... 4caf862618

The macOS app took any path under /Volumes to be its disk image. An app on an
external drive never updated, and a disk image mounted elsewhere, or a copy
Gatekeeper translocated, said it would update itself and could not. It now reads
the volume's read-only flag. The release of 0.1.0 found this: the runner works on
an external drive, so the Apple silicon build failed its own update-status check.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

dcharlot referenced this pull request 2026-11-02 13:15:55 -05:00

wai-quantum-qpu and wai-quantum-cli: a job on a provider outlives what sent it #581

dcharlot merged commit 6fc7a81e56 into main 2026-11-02 18:27:38 -05:00

dcharlot referenced this pull request from a commit 2026-11-02 18:27:39 -05:00

Merge pull request 'wai-quantum-desktop 0.1.1: an app on an external drive updates itself, and one on a disk image does not' (#580) from wai/quantum-desktop-0.1.1-b into main

Sign in to join this conversation.

Reviewers

No reviewers

Labels

Clear labels

No items

No labels

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

Transaction-Science/open-standards!580

No description provided.