eeu.pol / eeu.pot / eeu.pmp — Postal-Code Files (Empty)

Status: ✅ Identified — genuinely empty on this disc, eeu.mod's schema reconstructs the intended design. · 94 bytes each (header only, no body) · NOT_COMPRESSED

Three files, one finding, same family as eeu.pcl and eeu.pmc/eeu.pmm: a bare 94-byte header with zero body and zero records. But eeu.mod's own schema gives each of them a real, informative per-record field list — enough to reconstruct what the whole postal-code subsystem's intended design looked like, even with no populated content on this disc to check it against.

The files themselves — fully characterized, nothing left to decode

All 3 share the exact same 94-byte template as eeu.pcl (identical header bytes except the file_type byte): file size is exactly 94, total_size (bytes[90:94]) also reads 94 — an exact match, not one of the 2 known "stores body size instead" exceptions — and record_count_lo16 (bytes[86:88]) reads 0. file_type (bytes[84:86]): eeu.pmp=65, eeu.pol=61, eeu.pot=62 — each unique, confirmed not the same numbering as files.cfg's own fileId.

The disc's own files.cfg comments:

34 = pol, 0, cached  # postalcode list file
35 = pot, 0, cached  # postalcode tree file
38 = pmp, 0, cached  # postalcode merge postalcode file

What eeu.mod's schema reveals about each file's intended design

Pulling each block's real (non-boilerplate) field list directly (research/mod_reader.py's extract_blocks()) gives a coherent picture of a 3-stage postal-code lookup pipeline, none of it populated on this disc:

eeu.pot (postalcodeTree)

Real fields: key, nextSelectableCharTreeIndex, nextSelectableCharTreeCount, startDataListIndex, dataListCount.

Byte-for-byte the same field-name template already found for roadTree (eeuz.rt) and cityTree (eeuz.ct) — see Name Search Catalog. eeu.pot was designed as a character-trie search index over postal-code strings, using the exact same data structure already used for road-name and city-name autocomplete/search. The container differs even though the node schema is identical: eeuz.rt/.ct are FLAT_COMPRESSED, eeu.pot is plain NOT_COMPRESSED (per files.cfg's own compressionType column).

The exact byte-level trie-node encoding itself is still not fully cracked even for the populated eeuz.rt/.ct (research/city_reader.py's own docstring calls it "the same still-uncracked variable-node structure") — so eeu.pot being empty loses nothing that was otherwise crackable this session either way.

eeu.pol (postalcodeList)

Real fields: postalcode, Latitude, Longitude, ListIdMain.

A real postal-code-to-coordinate lookup record: the postal code string itself, a representative point (the disc's usual /100000 int32 convention elsewhere), and a ListIdMain foreign key — plausibly into the same kind of city/merge-list indices the .pmc/.pmm/.pmp trio manage, though this specific link was not independently confirmed (no populated eeu.pol was available this session to check against).

eeu.pmp (postalcodeListMergePostalcode)

Real field: a single mergedListIndex.

Structurally the third sibling of the already-cracked eeu.pmc/eeu.pmm pair — same "merge" naming convention, same lone-index shape. This cross-reference is also what resolved eeu.pmc/.pmm's own previously-open question about why their 4-byte physical record didn't match their schema's larger field count (see that page's "Resolved" section).

The whole postal-code subsystem, put together

Together the 3 "merge" files (.pmc city-side, .pmm type/list separator, .pmp postalcode-side) read as a set of redirect/ consolidation tables for cases where postal codes and cities don't map 1:1 (one postal code spanning multiple cities, or one city needing multiple postal-code entries) — a real, sensible design, just never populated on this East-Europe V17 release.

Combined with eeu.pmc/eeu.pmm's finding that they carry a provable placeholder identity array rather than real content, the coherent conclusion for the whole file family is: the entire postal-code subsystem (.pol/.pot/.pmm/.pmc/.pmp) was designed and schema'd but never populated on this specific disc. Plausibly this East-Europe dataset's country set didn't have licensed/ available postal-code data at build time, or the feature wasn't enabled for this particular release — not independently confirmed (no other region/market disc was available this session to compare against a populated postal-code subsystem).

Reader code

research/postal_reader.py — read_postal_header(), is_empty_placeholder().