After some investigations, I'm convinced that the members
'le32 num_entries_2' and
'le32 unknown_0x14'
of 'struct WimOverlay_dat_header' have the meaning of
'le64 next availabale data source id'
so this struct should be declared and handled like this:
struct WimOverlay_dat_header
{
/* Set to WIMOVERLAY_DAT_MAGIC */
le32 magic;
#define WIMOVERLAY_DAT_MAGIC 0x66436F57
/* Set to 1 (WIM_PROVIDER_CURRENT_VERSION) */
le32 wim_provider_version;
/* Set to 0x00000028 */
le32 unknown_0x08;
/* Set to number of WIMs registered;
* also the number of 'struct WimOverlay_dat_entry_1' that follow. */
le32 num_entries_1;
/* Set to next available data source id */
le64 next_data_source_id;
struct WimOverlay_dat_entry_1 entry_1s[];
} _packed_attribute;
Many thanks for your impressive work !!
Revealing unknown_0x14 in struct WimOverlay_dat_header
-
- Site Admin
- Posts: 474
- Joined: Sun Aug 02, 2015 10:31 pm
Re: Revealing unknown_0x14 in struct WimOverlay_dat_header
Thanks for the tip! Yes,it looks like your suggested interpretation is correct. I think I did not check what the file looks like after unregistering a WIM from the volume, since that is the case where the two fields diverge. next_data_source_id becomes greater than the number of entries, since data source IDs are not reused. I will update the code accordingly.
-
- Site Admin
- Posts: 474
- Joined: Sun Aug 02, 2015 10:31 pm
Re: Revealing unknown_0x14 in struct WimOverlay_dat_header
I've posted wimlib 1.9.2-BETA1. It should handle the field correctly.