FileTable.bin: the game's file table

Source

docs/formats/filetable.md

SHA-256

fffe581e…96ca7a1a

The index of every game file, at the root of Data/. The game looks a file up here by group and file ID (or by a hash of its name), and gets back its path under Data/ and its size; it then reads exactly that many bytes from the file. So a rebuilt file that changes size needs its record here changed to match (Rebuilding). The file is not wrapped (no RotXor or ZIP, containers.md). It has fields no code reads and record kinds no record uses; Gibbed reads them as the PSP game's. Terms are as in the glossary.

Layout

The parts follow each other with no gaps, in this order (confirmed: the R18 round trip finds each part ending where the next begins, and the path records ending at the end of the file; so did the exploration program):

Each part's count and offset in the shipped file are in its page's byte map (FileTable.bin).

Header

The loader (0x1402b1490) reads only name_count, group_count, file_records_offset and path_records_offset. The fields no code reads are named by position, or as Gibbed reads them (guess).

Name records

Let the game open a file by name: it hashes the name and looks the hash up here to get the file's group and file ID (0x1402af940, 0x1402b1700). If the hash isn't found, it opens the name as a path instead.

• likely: the game searches every name record for the hash, not just one group's, and takes the first match. Source: 0x1402b1700 (a linear search over all name_count records).
• confirmed: the records are in group order, only for groups 100, 700 and 1001, matching those groups' name_index and name_count (each group's count is on its page); every other group has name_count 0 and name_index 0xFFFF. Source: the R18 round trip (it derives both from the name records' group_ids); exploration program.
• confirmed: for group 100, every hash is the FNV-1 hash of the file's path in its path record. For group 1001, every hash is the FNV-1 hash of the file's name in upper case, without folder or extension (ENTRY_UNIT_001 for battle/entry/entry_unit_001.dat). Group 700's one record (WarrenReport/WarrenReport.dat) hashes none of that path's spellings tried (with or without folder, extension or Data/, in each case and with either slash). Source: exploration programs namehash.cs and variants.cs (R31, 2026-10-11); the toolchain's NameHash.
• confirmed: the name records cover only whole files: no hash is any spelling of a name Gibbed gives a pakd entry (308 entry names in configs/reborn/filetables/*.toml, each tried alone, under its file's and group's paths, with and without extension, in each case and with either slash). So Gibbed's entry names (arms_data.xlc, battle_text.xlc, …) can't be checked against the game's hashes, and don't count as the game's names. The one other match, menu\mapname\fr-fr\stronghold_012.dat against record 1001/405, is a collision: that record's hash is also ENTRY_UNIT_ + its own number. Source: namehash.cs.

Group records

A group is the first of the two IDs a file is opened by. It isn't a folder: group 500 spans many menu/ folders and group 300 SaveThumb/common, ScreenShot, saveicon and system, while object/ is split over groups 20 and 30, event/scene/ over 901–909 and worldmap/ over 800 and 850 (exploration program ft.cs). No game string names it.

Range records

A range is a run of consecutive file IDs in one group, sharing one record kind.

• likely: the file record for ID f is at file_records_offset + file_record_offset + record_size × (f − base_file_id). Source: 0x1402b1350.
• confirmed: ranges are in group order, each group's range_count of them from its range_records_offset, and their file records follow in the same order, back to back: each file_record_offset is 4 × the files of the ranges before it. Source: the R18 round trip; exploration program.

File records

All of Reborn's file records are kind 0 (above): a 4-byte offset into the path records.

Record kinds 2 to 5 hold an offset (shifted by the group's offset_shift) and a size, 2 or 4 bytes each, into one big data file. The game still reads them (0x1402b1280), but no record in Reborn's file uses them; Gibbed reads them as the PSP game's.

Path records

One record per file record.

• confirmed: records are back to back, in file-record order, each used by exactly one file record, each padded with zeros to the next multiple of 8, and the last ends at the end of the file. Every path is ASCII. Source: the R18 round trip; exploration program.
• confirmed: for every file record whose file is in Data/, size is the file's size on disk. The others name files that aren't in Data/, and all have size 0 (each group's count is on the file's page, under Size 0). Source: the gate FileTableGivesEachFilesSizeAndTakesARebuiltOne over the toolchain's decode (R18); exploration program over the game's Data/.

How the game reads it

How the executable turns a file ID or name into bytes: it loads this table, looks the file up in it, and reads the file from Data/. The functions are in the names list.

Loading the table

• likely: the game loads one file table, once, at startup: the game's setup (0x1402c1970) calls FileTable_Mount with no path, retrying until it succeeds, and nothing else calls FileTable_Mount or FileTable_Load, directly or through a stored pointer. Source: 0x1402c1970 (calls at 0x1402c1d8b and 0x1402c1da2); exe.calls; exploration program exescan.cs (no other call, jump or pointer to either function in the executable).
• likely: that table is Data\FileTable.bin in the executable's folder. With no path, FileTable_Load opens the bare name FileTable.bin; no table holds its hash yet, so it's opened as a path under the data root, which is the executable's folder plus Data\. Given a path, it would open the path and FileTable.bin joined with no separator (%s%s). Source: 0x1402b1490 (format string at 0x14067dbc8), 0x1402af940 (fallback to a path), Mx::Blade::BladeFramework::vfunction7 0x14015d120 (GetModuleFileNameW, then Data\, kept by the file manager at 0x140f6c770), 0x1402b0560 (copies it to the data root at 0x140ce3980).
• likely: FileTable.EDAT is never loaded: FileTable_Load picks it over FileTable.bin only when its fourth argument is set, and its one caller, FileTable_Mount, always passes 0. Source: 0x1402b05b0 (calls FileTable_Load(slot, path, 1, 0, 0xFF)).
• likely: the game reads the table whole, and checks only that it read as many bytes as the file has on disk; there is no hash or checksum over it. Source: 0x1402b1490 (opens with 0x1402af940, size from the file system via 0x140295760 with its size flag set, compares with the bytes read by 0x140295990).
• likely: mounting also sets every group's base_offset to 0 in memory (FileTable_Load's third argument); it is 0 in every group already. Source: 0x1402b1490.
• likely: the file system has 64 slots of 0x88 bytes for tables, and beside them a list of pointers to the loaded ones, sorted after each mount by a signed 16-bit priority in the slot (at 0x42), lowest first, with empty entries last (as 0x7FFF). Every mount gets priority 0xFF, so the sort decides nothing, and qsort leaves the order of equal entries unspecified. Opening by ID searches the sorted list; opening by name searches the slots in slot order, so the first table mounted (slot 0) first. Source: 0x1402b05b0 (first free slot, priority from FileTable_Load's fifth argument, then qsort), 0x1402af4f0 (comparator), 0x1402af860 (sorted list at 0x2270), 0x1402af940 (slots from 0x70); ISO C, qsort ("the order of equivalent elements is unspecified").
• likely: so a mod can't add a table of its own without changing the executable: only Data\FileTable.bin is ever loaded. Code injected into the game to mount a second table wouldn't reliably win either: with the same priority as the game's table, whether it's searched first by ID is up to qsort, and by name the game's table is always searched first. Source: the facts above.

Opening a file by ID

• likely: given a group ID and file ID, the game finds the group, then the range holding the file ID, then its file record, and from the record the file's path and size. Source: 0x1402af860 → 0x1402b1350 (group, range and file record), 0x1402b1280 (size), 0x1402b1340 (path).
• likely: it joins the path to its data root and opens it without asking the file system for the size; the handle's size is set from the table, and that many bytes are read. No hash or checksum of the file is checked. Source: 0x140295760 (size flag clear, root from 0x1402af520), 0x1402af860 (stores the table's size in the handle at 0x48), 0x140295990 (reads the handle's size).

Opening a file by name

• likely: given a name, the game hashes it with FNV-1 (32-bit) and searches the name records of every loaded file table for the hash; if it's found, it opens that group and file ID as above. If not, it opens the name as a path under the data root, with its size from the file system. Source: 0x1402af940 (hash, search, fallback), 0x1402b1700 (name-record search).

Reading the bytes

What the game does with the table's size once a file is open, and so what happens when the file on disk is a different size.

• likely: reads are queued, not done at once: 0x1402af220 adds a request (handle, buffer, size) to a list ordered by priority, and worker threads named FileSystem::Read (0x1402b0140) and FileSystem::ReadStream (0x1402afef0) carry the requests out; a third, FileSystem::Decomp (0x1402af110), unpacks wrapped files (containers.md). Source: 0x1402ae340 (creates the three workers by name), 0x1402af220.
• likely: the size asked for is the handle's size, which for a file opened by ID is the table's size, and the buffer the game reads into is allocated at exactly that size. Source: 0x1402af860 (stores size in the handle at 0x48); 0x1402959a0, 0x140295b20 (queue a read of the handle's size); 0x140295bc0, 0x140295c90 (allocate a buffer of the handle's size, File\FileDesc.cpp).
• likely: each read opens the file, seeks, and calls fread for the requested size; it fails only when fread returns 0 bytes, so a short read counts as success. The layers above don't look at the count: the game records the requested size as the bytes read. Source: 0x1402afd20 (ignores the stream's result, sets bytes read at 0x88 to the requested size) → 0x1402956d0 → Mx::IO::Blade::BladeFile::vfunction3 (0x140179470, advances by the requested size) → 0x14010b190 → bl::fio::FileIO::vfunction3 (0x14012bea0: _fsopen, fseek, fread; error 0x1A only when nothing was read).
• likely: so the game never compares a file's real size with the table's. When the file is longer, only the first size bytes are read. When it's shorter, the read still succeeds, and the rest of the buffer is left as it was allocated (not cleared). Source: the three facts above.
• likely: for a RotXor-and-ZIP .dat, the game uses only the bytes up to the end of the member's compressed data; the central directory and end record after it are never read (containers.md). So any size from the end of the compressed data (30 + n + csize) up works, and a smaller one cuts the compressed data short. An MLZ0 file is different: the game takes size − 8 as its compressed length, so its size must be exact. Source: 0x1401a2a00 (reads the local header and inflates compressed_size bytes), 0x1401a29e0; for MLZ0, 0x1401a2a00 (LZ4_decompress_safe of size − 8 bytes from byte 8).

Decoded data

tor export writes the table as a folder payload.filetable/ with one .jsonl per kind of record (toolchain/README.md (../../toolchain/README.md#decoded-data)). The counts and offsets the Rebuilding rules derive aren't columns; they're in the file's .bin.

The view exe.file_opens joins files.jsonl to the executable's calls that open files (The indexes).

Rebuilding

What a rebuild needs. confirmed for unchanged rows: the table rebuilds byte for byte from its rows, with every count and offset derived as below (see Method).

• A mod that changes a file's size changes the game's own Data\FileTable.bin: the game loads no other table (Loading the table).
• Parts are written in the order of Layout, with no gaps. Every count and offset is derived from the records: name_count, group_count, each group's range_count, range_records_offset, name_count and name_index (0xFFFF when it has no name records), each file_record_offset, file_records_offset, path_records_offset, and each path_offset.
• Ranges follow their groups' order, and a group's name records are one run. Files follow their ranges' order, each range's file_count of them with IDs from its base_file_id up. Rows that break this are refused with an error.
• Only record kind 0 is written: the file records of the other kinds hold an offset and size into one big data file (File records), which Reborn doesn't use; a range of another kind is refused.
• Each path record is the path, a NUL, the 4-byte size, and zero bytes up to the next multiple of 8 from path_records_offset. A longer or shorter path moves the path records after it, and their path_offsets are worked out again.
• Every other field is kept as it is in the original (the fields no code reads, the name hashes).
• For a rebuilt .dat whose path doesn't change, only its path record's 4 size bytes change; nothing moves. confirmed: the gate FileTableGivesEachFilesSizeAndTakesARebuiltOne rebuilds battle/battle_data_release.dat with a longer text key, sets its size with the toolchain (FileTable.SetSizes, by path), and the new table differs from the original only in those 4 bytes and decodes back with the new size.
• size is set to the rebuilt file's exact size. The game would also accept anything from the end of a ZIP member's compressed data up (Reading the bytes), but an exact size is what the game ships and the only value whose effect doesn't depend on that reading.
• Gibbed's RebuildFileTable does the same: it reads the table, sets each named file's size to its size on disk, and writes the table again. Source: Gibbed RebuildFileTable/Program.cs, FileTableFile.Serialize.

Leads

• What group 700's one name hash (0x4F63C3BF, WarrenReport/WarrenReport.dat) is a hash of: the name 0x14028bd80 and other callers of FileTable_OpenByName pass would tell.
• What the game uses obfuscated, in_install_data and install_base_offset for, if anything; nothing in the lookup reads them. A reader of obfuscated (the movie path 0x14026c260 → 0x1402b0970?) would settle it.
• Title IDs: ULJM05753 and NPJH50348 look like Sony PSP product codes; with a primary source for Sony's title-ID format, title_id_1/2 could be named from the data.
• The file records without a file in Data/: which groups they are in, and whether they're other platforms' or cut files.
• Confirm in game (R14) what Reading the bytes predicts: a .dat whose size is a few bytes short of the file (cutting only its ZIP end records) still loads, and one cut into its compressed data doesn't.
• What the game's setup sets right after mounting the table: 0x1402b05a0 sets byte 1 of an 8-byte array at 0x2B08 in the file system, which FileSystem_QueueRead (0x1402af220) compares per read channel with the array at 0x2B10.
• 0x14028bd80 looks names up by hash in group 500 only (0x1402b04d0 → 0x1402b1650), but the shipped table has name records only for groups 100, 700 and 1001: what it opens, and whether it ever finds anything.
• local/exe/decomp/ is stale: 0x1402ae180.c still shows 0x1402af220 as File_Read, several named functions show as FUN_…, and comments cite a docs/executable/file_loading.md that doesn't exist. Regenerate it after the names are applied.