Skip to content

Point read-data at the resolved data dir, not a relative token - #2

Merged
wormeyman merged 1 commit into
mainfrom
fix/read-data-path-on-non-mac
Aug 17, 2026
Merged

Point read-data at the resolved data dir, not a relative token#2
wormeyman merged 1 commit into
mainfrom
fix/read-data-path-on-non-mac

Conversation

@wormeyman

Copy link
Copy Markdown
Contributor

build_config_ini emitted read-data=__PATH__executable__/../data on every platform. That token is correct for a macOS bundle, where the binary sits at Contents/MacOS/factorio and data is one level up. Windows and Linux put the binary at bin/x64/, so the same token resolves to bin/data and the game refuses to start.

Measured on a real 2.1.14 Windows install, 2026-08-17

read-data=__PATH__executable__/../data     -> exit 1
    "There is no package core in V:/factorio-2.1.14/bin/data"
read-data=__PATH__executable__/../../data  -> exit 0

The fix

resolve_layout already works the data directory out correctly for every layout it supports. That value was simply not being used. So take it as a parameter and emit it absolute.

Branching the token on layout would also work, but it re-derives here what resolve_layout has already established, and a second copy of that knowledge is a second chance to get it wrong. An absolute path has no layout to know about, and is what both the macOS and Windows captures used on the day this was measured, producing identical dump bytes (sha256 acc944e6...).

Windows accepts either slash style, so Path::display() emitting native backslashes needs no rewriting: V:\factorio-2.1.14\data and V:/factorio-2.1.14/data both exit 0 and dump identical bytes. Measured, since a backslash in an ini value is the kind of thing that gets eaten.

Why no test caught it

The suite only ever ran on macOS, which is the one layout the token was right for. This came out of a separate experiment asking whether --dump-data is byte-identical across architectures. It is - same build, mac-arm64 and win64 both produce sha256 acc944e6... from byte-identical inputs. But going to look turned up this, which is the same platform blind spot in a place nobody was checking.

The new test asserts the token is absent for a bundle path, a Linux path and a Windows path, so that blind spot cannot silently return.

Checks

cargo fmt --all -- --check, cargo clippy --all-targets -- -D warnings, and cargo test --all-targets all pass: 113 unit tests plus 6 install-gated tests. The byte-for-byte fixture gate still passes.

🤖 Generated with Claude Code

https://claude.ai/code/session_01P9FADuTnjE7SFEQWnpNhfc

build_config_ini emitted read-data=__PATH__executable__/../data on every
platform. That token is correct for a macOS bundle, where the binary sits
at Contents/MacOS/factorio and data is one level up. Windows and Linux put
the binary at bin/x64/, so the same token resolves to bin/data and the game
refuses to start.

Measured on a real 2.1.14 Windows install, 2026-08-17:

  read-data=__PATH__executable__/../data     -> exit 1
      "There is no package core in V:/factorio-2.1.14/bin/data"
  read-data=__PATH__executable__/../../data  -> exit 0

resolve_layout already works the data directory out correctly for every
layout it supports, and that value was simply not being used. So take it as
a parameter and emit it absolute. Branching the token on layout would also
work, but it re-derives here what resolve_layout has already established,
and a second copy of that knowledge is a second chance to get it wrong.

Windows accepts either slash style, so Path::display() emitting native
backslashes needs no rewriting: V:\factorio-2.1.14\data and
V:/factorio-2.1.14/data both exit 0 and dump identical bytes. Measured,
since a backslash in an ini value is the kind of thing that gets eaten.

Every test passed before this change because the suite only ever ran on
macOS, which is the one layout the token was right for. The new test asserts
the token is absent for a bundle path, a Linux path and a Windows path, so
the macOS-only blind spot cannot silently return.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01P9FADuTnjE7SFEQWnpNhfc
@wormeyman
wormeyman merged commit 5127255 into main Aug 17, 2026
1 check passed
@wormeyman
wormeyman deleted the fix/read-data-path-on-non-mac branch August 17, 2026 19:08
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant