Builder: the first build after the next release spends ~8 minutes opening every game file (damaged-texture check, one file at a time) #2754

Open
opened 2026-11-12 11:35:43 +00:00 by github-sync · 1 comment
Owner

@Jiro131 opened on GitHub · 2026-11-12 11:12 UTC · original

Why it matters: #2391 (merged Nov 11, in no release yet) bumps the check version in .hookshot_romfs_checked, so every game folder already checked runs nup.damaged_game_files again on its first build with the next release. The extraction's list of damaged files (#1885) is deleted after the first check, so that build opens every romfs .zs file (102,185), one at a time. On Windows each first open of a file took about 4-5 ms here, which I attribute to Windows Defender scanning it (not confirmed with the scanner off): the build shows only its "checked N of 102,185 files" progress for about 8 minutes.

Builder version

main at ba005ca4, built from source with nx2/make_game.py --nup (the Builder's own steps).

How you built

A fresh unpack into a new game folder; then .hookshot_romfs_checked removed, as the check-version bump does; then the same build again. The full check then runs over files not opened since they were written.

Game files given to it

A complete base-game .nup (about 23.8 GB).

The error

No error: a long wait. From the second build's log:

checking your game files for damaged textures (once after an unpack): every .zs file is opened, which can take minutes
checked 102,185 of 102,185 files (100%, 486 s)

Two separate fresh folders: 486 s and 492 s, out of builds of 490 s and 509 s. The same check run again over the same files takes 5.0-5.9 s.

Visual Studio or Build Tools version, and Windows SDK version

None: the C compiler was the Builder's own llvm-mingw (the check runs before any compile).

Operating system and free space on the output drive

Windows 11 Home 10.0.26300, Windows Defender on; i9-13900K, 64 GB, NVMe; 115 GB free.

Score

As in docs/workflow.md: S3 (a one-time wait; the build finishes) x reach 0.57 (Windows; every installed game on its first update after #2391) x confidence 1.0 (reproduced, log above) = 0.57.

Claim

I'm taking this, on an RTX 4090, i9-13900K and Windows 11. The plan is to open the files from a thread pool, keeping the results and the progress in the listed order. Measured on fresh unpacks, two interleaved pairs: 486 and 492 s before, 27 and 28 s after, with the same files found. The PR follows a game run on that build.

Tracking: #2505

Before you send it

  • I'm on the newest release, or it still fails on it. (main, newer than the newest release)
  • I searched the open issues for this error.
  • I'm not attaching game files or anything built from them.
> [@Jiro131](https://github.com/Jiro131) opened on GitHub · 2026-11-12 11:12 UTC · [original](https://github.com/NotRexed/Hookshot/issues/2754) **Why it matters:** #2391 (merged Nov 11, in no release yet) bumps the check version in `.hookshot_romfs_checked`, so every game folder already checked runs `nup.damaged_game_files` again on its first build with the next release. The extraction's list of damaged files (#1885) is deleted after the first check, so that build opens every romfs `.zs` file (102,185), one at a time. On Windows each first open of a file took about 4-5 ms here, which I attribute to Windows Defender scanning it (not confirmed with the scanner off): the build shows only its "checked N of 102,185 files" progress for about 8 minutes. ### Builder version `main` at ba005ca4, built from source with `nx2/make_game.py --nup` (the Builder's own steps). ### How you built A fresh unpack into a new game folder; then `.hookshot_romfs_checked` removed, as the check-version bump does; then the same build again. The full check then runs over files not opened since they were written. ### Game files given to it A complete base-game `.nup` (about 23.8 GB). ### The error No error: a long wait. From the second build's log: ``` checking your game files for damaged textures (once after an unpack): every .zs file is opened, which can take minutes checked 102,185 of 102,185 files (100%, 486 s) ``` Two separate fresh folders: 486 s and 492 s, out of builds of 490 s and 509 s. The same check run again over the same files takes 5.0-5.9 s. ### Visual Studio or Build Tools version, and Windows SDK version None: the C compiler was the Builder's own llvm-mingw (the check runs before any compile). ### Operating system and free space on the output drive Windows 11 Home 10.0.26300, Windows Defender on; i9-13900K, 64 GB, NVMe; 115 GB free. ### Score As in docs/workflow.md: S3 (a one-time wait; the build finishes) x reach 0.57 (Windows; every installed game on its first update after #2391) x confidence 1.0 (reproduced, log above) = **0.57**. ### Claim I'm taking this, on an RTX 4090, i9-13900K and Windows 11. The plan is to open the files from a thread pool, keeping the results and the progress in the listed order. Measured on fresh unpacks, two interleaved pairs: 486 and 492 s before, 27 and 28 s after, with the same files found. The PR follows a game run on that build. Tracking: #2505 ### Before you send it - [x] I'm on the newest release, or it still fails on it. (`main`, newer than the newest release) - [x] I searched the open issues for this error. - [x] I'm not attaching game files or anything built from them. <!-- github-sync:item:2754 -->
Author
Owner

@Jiro131 commented on GitHub · 2026-11-12 12:13 UTC · original

PR: #2769 (the game run on that build is in its description and in docs/tested-configurations.md).

> [@Jiro131](https://github.com/Jiro131) commented on GitHub · 2026-11-12 12:13 UTC · [original](https://github.com/NotRexed/Hookshot/issues/2754#issuecomment-6823287753) PR: #2769 (the game run on that build is in its description and in docs/tested-configurations.md). <!-- github-sync:c:6823287753 -->
Commenting is not possible because the repository is archived.
No milestone
No assignees
1 participant
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
MagicBeanDev/Hookshot#2754
No description provided.