DBCache.bin: Difference between revisions

From wowdev
Jump to navigation Jump to search
mNo edit summary
mNo edit summary
Line 28: Line 28:
  } entries[];                  // fill until end of file
  } entries[];                  // fill until end of file


<tt>index_ish_in_file</tt> is weird since it can be duplicate but same index doesn't mean same <tt>table_hash</tt>, so it isn't "last wins". Possibly something like "push id"?
<tt>index_ish_in_file</tt> is weird since it can be duplicate but same index doesn't mean same <tt>table_hash</tt>, so it isn't "last wins". Possibly something like "push id"? Mirrors Hotfix.log's ClientAvailableHotfixes which infers "push id" is correct

Revision as of 14:01, 3 November 2017

The 7.2.0+ replacement for hotfix storage in ADB and Hotfix.tbl.

While it appears chunked, it is not. All blocks use the same 'HTFX' signature, but don't have a size, and have differing content based on location (i.e. the first 'HTFX' "chunk" is a header for the entire file, individual entries start with 'HTFX' as well).

struct {
  uint32_t signature;         // 'HTFX'
  uint32_t region_ish;        // 3 for eu, 4 for ptr, apparently 1 for us
  uint32_t build;             // client build this cache was created in
#if version >= 7.3.2 PTR
  uint32_t checksum[8];       // SHA? MD5? There is 32 unknown bytes in the header before the entries in 7.3.2 PTR
#endif
} header;

Client ignores region_ish and build blocks that don't match current binary. If header doesn't match, whole file seems ignored.

After the header, entries follow:

struct {
  uint32_t signature;         // 'HTFX'
  uint32_t region_ish;        // see header.region_ish
  uint32_t index_ish_in_file; // non-contiguous but ascending, sometimes duplicate, weird
  uint32_t size;
  uint32_t table_hash;
  uint32_t id_in_table;
  uint8_t is_valid;
  uint8_t padding[3];         // at least seems uninitialized in 24500
  char data[size];            // format depends on table_hash
} entries[];                  // fill until end of file

index_ish_in_file is weird since it can be duplicate but same index doesn't mean same table_hash, so it isn't "last wins". Possibly something like "push id"? Mirrors Hotfix.log's ClientAvailableHotfixes which infers "push id" is correct