【win备份还原工具开发日记】19：Windows 原生小镜像实测、PE 界面五项缺陷、PE 写盘安全修复与 RE 测试卷闭环

对应文档（同日 12 篇）：docs/20261005-0724-Windows原生小镜像实测与重定向复核-GPT-6.md、docs/20261005-0724-当前开发进度-GPT-6.md、docs/20261005-0724-下一步待实现-GPT-6.md、docs/20261005-1050-PE实机界面测试-先格式化后谎报成功等五项缺陷-Opus5.md、docs/20261005-1050-当前开发进度-Opus5.md、docs/20261005-1050-下一步待实现-Opus5.md、docs/20261005-2310-PE写盘安全修复与双环境实测-GPT-6.md、docs/20261005-2310-当前开发进度-GPT-6.md、docs/20261005-2310-下一步待实现-GPT-6.md、docs/20261005-2352-RE测试卷备份还原闭环实测-GPT-6.md、docs/20261005-2352-当前开发进度-GPT-6.md、docs/20261005-2352-下一步待实现-GPT-6.md

Windows 原生小镜像实测与重定向复核（07:24，v2.0.9）

1. 真正跑到 Windows 上去了：本机 122 项 + Windows 原生常规 135 项 + 单独跑的真实 DISM 在线内核集成 1 项，全部通过；发布程序在客体上做了 12 次命令行调用，退出码逐个符合预期（含 wim-info 不存在/损坏镜像退出 1、/Index:999 退出 1）。只改版本元数据与验收脚手架，没改一行产品 Rust 源码。

2. 确认了「条件命令真分支漏写」这个机制：if exist "present.txt" (echo SYS) else (echo NOSYS) > "result.txt" —— 文件存在时标准输出打了 SYS，但结果文件根本没生成；把整条 if/else 外加一层括号，才写出 SYS。旧报告里「重定向只作用于 else 分支」从待验证假设升级为本机复现。

3. 否定了一个笼统说法：echo VOLUME_PATH_OK > "\\?\Volume{真实卷标识}\...\volume-redirection.txt" 退出 0、文件真实写入。所以「cmd 一概不支持原生卷路径重定向」是错的——但也不能反推成所有工具/所有 PE 版本都支持。

4. 收紧了「读不到」的表述：干净场景读回路径确实不存在；预置旧 SYS 后再让写路径产出 NOSYS，读回仍是旧 SYS。NOSYS.Contains("SYS") = true、精确匹配 NOSYS == SYS = false——联合修复要路径同源 + 错误分类 + 精确判据，单改子串匹配不会反向把 NOSYS 判成系统。

5. 脚手架自己曝了两个问题：① 脚本以为设 TEMP 就能限定 Rust 临时目录，但 SYSTEM 账户实际用 C:\Windows\SystemTemp，测试其实已通过却在目录归属断言处停下；② PowerShell 5 重载数组时把前五条记录包成 value/Count 对象。两处都保留原始失败日志，没有伪报「一遍跑通」。

6. 边界写清：未进 PE、未格式化系统卷，GUI 点击、身份漂移、断电续跑、BCD 回滚、十分钟以上大镜像、真实系统卷闭环全部仍未测。

PE 实机界面测试：先格式化、后谎报成功（10:50，v2.1.1）

1. 第一次真的在 WinPE 里点产品界面：由 C:\Recovery\WindowsRE\Winre.wim 的私有副本注入验收驱动启动真实 WinPE（SystemDrive=X:，中文系统）；界面操作走一个仅用于验收的进程内驱动（枚举真实窗口、选真实下拉、点真实按钮），不抢宿主鼠标键盘。破坏性目标只有本轮新建的 128 MB 一次性 VHD（卷标 BRPE0804，PE 内挂 V:），操作前自检卷标与容量，不符立即拒绝。

2. 正例确实有效：点「备份系统」产出 r2-backup.wim（索引 1、24 字节，正是源盘 payload.txt 大小）；点「还原系统」正例里格式化真发生了——先放的 old-only.txt 被清除、payload.txt 内容与源一致。格式化与应用在正常路径上是有效的，缺的是失败判定与阻断。

3. P0，最严重的一条：反例实机复现数据丢失。镜像路径填一个确实不存在的文件 → 确认框文案正确 → 先「DiskPart 成功格式化该卷」→ 应用报「错误: 2 / 系统找不到指定的文件」→ 结果弹窗却写「还原完成」→ 再问「还原完成，现在重启进入系统？」。盘上哨兵与 payload 全毁。此前文档把它列为「静态推测」，现在有了实机证据。

4. P0，探测文件写读路径不同源：find-system.txt / format-check.txt / bcdboot-check.txt 产品写到 S:\ 卷根，读回却去找 S:\BackupRestore\logs\，读回路径根本不存在 → pe-drive.txt 变 0 字节 → resolve_drive("AUTO") 返回空串 → format 的系统卷保护判据恒为「非系统卷」、bcdboot 恒「跳过」。来源是 v1.8.1 提交 7613896「ESP 日志迁出根目录」只迁了读取侧，命令里的 > S:\x.txt 重定向目标一个都没跟着改。

5. P0，本地化字符串假设错误：代码两处注释坚称 *** NO MOUNT POINTS *** 是固定串、不随本地化变，但中文系统与中文 PE 实测都打 *** 无装入点 *** → esp_volume_path_for_task() 在中文系统上必定返回 None。影响不止 PE：Windows 侧「重启进入 PE」写 pe-task.txt 也走这个函数，返回 None 即写不进去——这是 v1.8.2「方案 A」引入的回归。

6. P1，中文输出被当成「无输出」：S:\BackupRestore\logs\backup-out.txt 确实存在、142 字节 GBK 文本（含「操作成功完成。」），但产品日志记 no output。根因是 read_to_string 要求 UTF-8、GBK 解码失败返回 Err。项目自己已有 decode_console_bytes 解码层（软硬件信息页在用），PE 任务分支就是没用。

7. P1，mountvol 退出码被当判据：日志报 mountvol S: /S FAILED with exit code 退出码 1，但同一轮 S:\ 下的文件写入全部成功，说明 S: 其实已挂载。项目注释早就写过「mountvol 返回码实机不可信」，esp_store_path_for_pe 却仍按退出码判，非零即返回 None → pe_task_execute 报 no config。

8. 顺带实测确认：PE 内盘符确实漂移（T:→D:、P:→E:、H:→F:、F:→G:），支持「保存的盘符不能当执行期身份」；还原确认框文案本身合格，问题不在确认环节，而在确认之后缺输入预检与失败阻断。

9. 收尾干净：本轮创建的两个测试 BCD 对象删除并回读确认，{bootmgr} default 仍为 {current}、无残留 bootsequence；注册 Winre.wim 哈希前后一致；每次 PE 部署/武装/返回/删除前各建并核验新快照，全程 ≤2 份。

PE 写盘安全修复与双环境实测（23:10，v2.1.2）

1. 写盘前统一预检闸：读本地镜像 → SHA-256 → 指定索引 → 展开容量 → 可选副档；系统意图要求镜像里能列出 SYSTEM 注册表文件、winload.efi、ntoskrnl.exe，缺失或未知一律在格式化前失败。

2. 身份与角色绑定：请求保存磁盘/分区/卷 GUID、类型、位置、大小、序列号，启动后按稳定卷路径回读、写命令前复核现场编号；拒绝镜像、日志、运行程序、当前系统、恢复载荷与目标冲突，以及保留分区。

3. 失败即停 + 结构化结果：execute_pe_task_line 不再返回 ()，格式化/应用/引导逐步持久记录，任何一步失败停止后续；界面只有全部成功才报完成、才问重启；数据覆盖明确跳过格式化和引导。自动请求改成 BackupRestore/pe-requests/<id>.json + 写盘前独占 .claimed，失败保留领取记录、下次不自动重放；旧 pe-task.txt/pe-click.txt 保留原件但停止执行。

4. 路径同源 + 解码层 + 原生 ESP 枚举：命令输出写入、进度读取、最终回读共用同一输出对象，保留原始字节、支持 UTF-8/UTF-16/OEM；ESP 改用原生卷枚举 + 验证分区类型与 BCD 路径，不再解析本地化的 NO MOUNT POINTS。

5. 验证结果：本机 131 项、Windows 原生 145 项、一次性 VHD 原生集成通过；cargo fmt --check、clippy -D warnings、Windows ARM64 发布构建全部通过（没有为显示全绿而放宽规则）。

6. 真实 PE 界面六个用例：备份通过；缺镜像 / 数据镜像误当系统镜像 / 索引 999 / 损坏镜像 / 镜像存在目标卷上——五类全部「操作失败」，零格式化调用、零「还原完成」、零重启询问，哨兵内容与卷序列号均不变。最终落盘 PE_UI_SAFETY_PASS backup=pass rejected=5 target_unchanged=true。

7. 校准了旧草案的错误判断：统一遵守 D01～D10，订正「精确匹配会把 NOSYS 当 SYS」（逻辑相反）、「不改名即可安全续跑」、「角色未知可凭确认放行」等说法。

8. 交付边界不含糊：完整系统还原后的启动、第二系统启动、真实断电恢复、完整 BCD 回滚、主 recover-env 状态机、硬盘模式 PE 安装器都未在本轮验收；Winre.wim 本轮开始与结束均为 Disabled，未重新注册。

RE 测试卷备份还原闭环实测（23:52，v2.1.3）

1. 第一次跑通产品的正常 RE 链路（不是 PE）：走发布程序自己的 prepare 入口，由产品准备独立 WinRE 副本、注入同源 Recovery.exe、创建并武装临时 BCD 条目、重启；进 RE 后真实 DISM 捕获/应用，清完自身启动对象再自动重启回 Windows。没有手动替换捕获、格式化、应用或清理任一步。目标是 T:（磁盘 0 分区 5、5 GiB 数据卷），C: 全程没当源、没当目标、没被格式化。

2. 同一份「成功」里埋着一条不能推的结论：还原日志明确写 data-volume restore: target has no SYSTEM hive; skipping BCDBoot——数据卷跳过了引导修复，也没有验证恢复后的系统能不能启动。数据卷闭环通过 ≠ 完整系统恢复通过，这条边界后面几天才被 C: 真正补上。

3. RE 内盘符照旧漂：T:→D:、H:→F:，源/目标/镜像全按稳定分区身份挂载，实际格式化日志确认为磁盘 0 分区 5，不认桌面盘符。

4. reagentc /disable 会连坐：它会删改恢复关联，并把原恢复目录里的 WIM 与 boot.sdi 一起移走。直接导入事前 BCD 导出能恢复配置，但本机会新增 6 个固件应用条目；只按「导入后新增的 GUID」删这 6 个，再恢复事前 ReAgent.xml、补回被移走的原件（补 SDI 前另建快照），最终完整 BCD 枚举、reagentc /info、原件摘要与测试前逐字一致。

5. 脚手架误报，没记成通过：PowerShell 直接调用图形子系统程序并重定向文件时，进程确实在跑但 $LASTEXITCODE 为空，首次备份包装脚本误报失败（产品其实已完成正常 RE 事务）。改用 System.Diagnostics.Process 持句柄、异步读两路输出、等退出并验真实退出码；空退出码不记为通过，最终判据落在持久任务、真实命令日志和镜像/文件回读上。

6. 数字留痕：镜像索引 1、名称 RE213，逻辑内容 32,505,896 字节、物理 WIM 1,307,057 字节（源里有大量零填充，不代表系统备份性能）；还原后 NTFS 卷序列号 94B52928→2E0FC364、分区 GUID 不变；6 个文件改/删/增全部按摘要还原正确。

7. 回归与回收：本机 131 项、Windows 常规 145 项通过；EXE 2,037,248 字节；6 份快照全程 ≤2 份，结束恢复 WinRE 原禁用状态。