 AskaEth
|
36ff193609
|
fix(m171): 跨卷替换改成「目标同目录中转名 + 同卷原子改名」
已发布版本上的真 bug：暂存包在 <数据根>/cache/update/staging，目标 exe 在安装目录，
两者不同卷（便携版放 U 盘 / 数据根在 D 盘而程序在 C 盘 / 部分 macOS 配置）时
`rename(staged → dest)` 直接报 EXDEV / ERROR_NOT_SAME_DEVICE（io::ErrorKind::CrossesDevices），
更新必然失败，而 is_transient 不含 CrossesDevices，也没有任何降级路径。
复现（本机真跨卷：C:/Temp NVMe ↔ D:/Temp 机械盘，原实现）：
InstallFailure { error: UpdateError { kind: Io, message: "系统无法将文件移到不同的磁盘驱动器。
(os error 17)", path: Some("D:/Temp\ull-xdev-…\app\ull.exe") }, rolled_back: true }
失败点就是 `rename(暂存包 → dest)`；唯一调用方是 core::update::job::Job::apply（CLI/GUI 共用）。
修法（不把原子替换退化成可能留半截的复制）：
0. 新包 → <目标同目录>/.<文件名>.ullnew-<pid>-<seq> 同卷 rename；跨卷才 copy 到该中转名，
并核对写出字节数（少了直接判失败）
1. dest → <同目录 .ullold-…> 旧版本先安全落地
2. rename(中转名 → dest) 同卷，原子
3a. 成功 → InstallReceipt；3b. 失败 → 回滚 + 清中转名
目标路径上的新字节只来自一次原子命名，任何时刻都不是半截文件；同卷路径一个字节都不多搬
（注入用例断言 copies == 0，rename 恰好 3 次）。
备份清理策略一并定死：成功后只留最近一份 .ullold-*（更早的与残留的 .ullnew-* 删掉，
别的程序名的备份不碰）。旧行为是每次 apply 留一份、全仓无人调 remove_backup ⇒ 无限堆积。
顺手把文件动作抽成 replace_io::ReplaceFs（真实现 = std::fs），让「跨卷被拒」「复制到一半
失败」「改名失败」成为确定性输入；判据与顺序仍在 install 里，注入改不了。
守卫（都做过变异实测，均能变红）：
* install_xdev_cases：真跨卷安装成功且目标字节完整（去掉降级 → 红，报 os error 17）
* install_io_cases：跨卷降级只复制一次 / 半截复制后目标仍是旧字节且无 .ullnew- 残留 /
短复制被字节数判据拒掉 / 最后一步改名失败回滚并清中转名 / 同卷 copies == 0
* cli update_e2e_test::installs_across_volumes_from_the_cli：数据根一卷、安装目录另一卷，
整环从 CLI 入口跑通（去掉降级 → 红，输出 update_apply_failed + os error 17）
|
2026-11-08 13:06:57 +08:00 |
|
 worker-updatee2e
|
28bf104041
|
fix(m169): 复审 r1 五条 p2 —— 守门开一个极窄 allowlist 并把 E2E 真接进 CI
r1 复审（reviewer-updatee2e-r1，p2-5items，均不挡合并）逐条落地：
P2-3（本轮主产出）守门把「E2E 进 CI」这条路堵死了：`scan_enabling_text` 对 workflow 里任何该
feature 字面量判红，于是 `cargo test --release … --features update-test-source --test
update_e2e_test` 这种**合法调用**也红，自己登记的 follow-up 无法实现。现在：
- `ALLOWED_STEP = {workflow: .github/workflows/ci.yml, name: update-e2e,
must_contain: --test update_e2e_test}`；按 `- name:` 把 workflow 切成步骤块再判，文件名 / 步骤名
/ 命令行**三者任一不符即红**（job 名不参与判据：改 job 名不该解锁新能力）。
- `ci.yml` **新增一个独立 job** `update-e2e`（windows-latest、timeout 45m、release 档；现有 job
一行未动，纯追加 27 行）。只在 Windows：夹具的「真形状」是裸 `.exe` + `portable-exe`，Linux/macOS
的真实产物是 `.tar.gz` + `portable-zip`（会被 `ensure_self_replaceable` 直接拒），在 ubuntu 上跑绿
是假绿。不降 debug：`debug_assertions`/优化/panic 行为都不同。
- self-test 覆盖 allowlist 六向量（允许 / 换文件 / 换步骤名 / 缺 `--test` / 发布工作流 / ci 内另一步）。
P2-2 守门 8 条绕过：注释剥离改**引号感知**（`echo "#"; cargo …` 不再吃掉真命令）；扫描面扩到
`.github/actions/**`、`packaging/**` 递归子目录、`Makefile|justfile|Taskfile` 第二构建入口；
`--all-features` 之外补 `cargo hack --feature-powerset|--each-feature|--all`。大小写/下划线变体按
复审结论写进「抓不住」表（cargo feature 名敏感，写错编不过，不算漏检）。
P2-1 GUI 人工验收命令根本跑不起来：`-p unlucky-launcher-iced` 是 bin 名，改成 package 名
`-p unlucky-app-iced`（app-iced / presenter 两处，并写明 `-p` 只认 package）。
P2-5 夹具缺「不给 --dest 就 panic」的结构性保险：`Fixture::run` 加两条断言——`apply` 必带
`--dest`、`--dest` 不许等于本进程 exe 的 canonical 路径。抓得住「以后有人手写 fx.run(&["apply"])」，
抓不住「绕开 Fixture 直接调 unlucky_cli::run」。
P2-4 夹具「真形状」只在 Windows 成立：写进 `tests/support/update_e2e.rs` 文件头（说明 Linux 上跑绿
是假绿、CI 因此只在 Windows），**不改断言**。另按复审 ⑤ 补一行：失败路径三例抓不住回滚/备份
（摘要失败发生在 install_staged 之前），回滚靠正路备份断言 + install_cases。
跨卷替换 bug 按 tower 指令**未动**（另开 mission）。
验证：守门正式扫描 + self-test 绿（14 红 / 3 绿）；真仓注入 6 组（基线绿、步骤改名红、缺 --test 红、
搬进 release-build 红、改 --all-features 红、还原绿）；E2E debug 6 绿、**release 6 绿**；
`cargo clippy -p unlucky-cli --all-targets --features update-test-source -- -D warnings` 干净；
`cargo fmt --all -- --check` 干净；全仓 400 行扫描无超限（守门脚本 379 行、ci.yml 317 行）。
⚠ 未验：CI 里 E2E 真的跑起来这件事本机验不了——只证明 workflow 写对 + 守门放行，首次真实运行要等
推送后看 Actions。
|
2026-11-08 11:12:11 +08:00 |
|