Files
benilla-octo/crates
gromandClaude Opus 5 73bc9a9e8e app+formats: name the realm files a shadowing archive holds stale
The archive found holding an old copy of the realm's own `FrameXML.toc`
is holding an old snapshot of the realm's interface, not one old file.
`Chain::copies` answers which archives hold a name and at what size off
the hash and block tables alone, decompressing nothing, so the boot log
can now name every row of the realm's toc whose winning copy comes from
that archive while the realm's own has a different one.

On grom's install that is ten, and it is the better half of the finding:
`GlobalStrings.lua`, five `OctoLocale` files, `AIO.lua` — the client and
server's whole transport — the calendar, the challenge tips and the
radio all load as an August `patch-A.mpq` has them, because a letter
patch outranks the realm's `patch-5.mpq`. `Spell.dbc` is shadowed the
same way, 20 KB behind.

Reported and not repaired, deliberately: shadowing a file with different
content is what a patch archive is *for*, so outside the toc — where
"holds every row the winner does, plus more" is a decidable relation —
this client cannot tell a stale copy from an intended override. The real
1.12 client reads the same copies, so this is a fix on disk, and the
line is what makes it findable instead of invisible.

`richest_toc` splits the superset rule out of `realm_toc_rows` so it is
testable without client data, which is where it ships from: the winner
stands unless a shadowed copy drops nothing, a longer copy that drops a
row is passed over, and the caller is told which archive it read so it
can say so. The staleness report is checked against the real chain and
every row it names must really differ in size between the two archives,
so it cannot be noise. The 269 data-gated failures remain identical to
the baseline at HEAD, name for name.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SgstFWtn1RxEJ5kVrpgYwn
2026-10-23 16:52:40 -06:00
..