exFAT reader: FAT held in memory, a cursor so a big file's chain is not re-walked per read,
runs of consecutive clusters read in one call; hashing on all cores; verify_chunk_kib on the
image build request with a Convert preference (8 MiB measured fastest, 169 MiB/s -> 3.7 GiB/s).
Game page: the Overview card that repeated the hero is gone; path, last played and captures
live in the hero; each copy is one compact row with a primary action and an overflow menu.
7z: lzma-rust2 raises "dist overflow" as ErrorKind::Other; it is now a corrupt-archive fault
that names the entry, so the queue stops instead of retrying the same bytes.
Console to console: route auto/direct/relay and an optional dial address per pair, in the
send dialog and the engine request.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EU1Z2mdhAxBrH1yb48pxik
sevenz-rust2 turns 7z sizes (u64 in the format) into usize before using
them as read limits: a block's packed size caps the decoder's input, and
block and file unpacked sizes cap the output and the CRC check. On the
32-bit Android build (armv7, in the APK next to arm64) usize is 32 bits,
so a limit past 4 GiB wraps: a 4.7 GB block was cut to 405 MB of input,
the LZMA decoder ran out inside a chunk and said "dist overflow", and any
file over 4 GiB was cut short. Game backups are tens of GB in one block.
sevenz-rust2 0.23.0 is vendored in third_party/ (as unrar is) with those
sizes kept u64 end to end; nothing changes on 64-bit. 0.24.0 still has
the casts. Verified on linux/arm/v7: a 4.7 GB single-block archive failed
after 405 MB before and decodes in full with its CRC after, and 6 GiB of
LZMA-coded output decodes correctly.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Ub1mez9eaVtTF8pMEFXvA9
phantomptr