+/* On-disk format of a WIM dentry (directory entry), located in the metadata
+ * resource for a WIM image. */
+struct wim_dentry_on_disk {
+
+ /* Length of this directory entry in bytes, not including any alternate
+ * data stream entries. Should be a multiple of 8 so that the following
+ * dentry or alternate data stream entry is aligned on an 8-byte
+ * boundary. (If not, wimlib will round it up.) It must be at least as
+ * long as the fixed-length fields of the dentry (WIM_DENTRY_DISK_SIZE),
+ * plus the lengths of the file name and/or short name if present.
+ *
+ * It is also possible for this field to be 0. This situation, which is
+ * undocumented, indicates the end of a list of sibling nodes in a
+ * directory. It also means the real length is 8, because the dentry
+ * included only the length field, but that takes up 8 bytes. */
+ le64 length;
+
+ /* Attributes of the file or directory. This is a bitwise OR of the
+ * FILE_ATTRIBUTE_* constants and should correspond to the value
+ * retrieved by GetFileAttributes() on Windows. */
+ le32 attributes;
+
+ /* A value that specifies the security descriptor for this file or
+ * directory. If -1, the file or directory has no security descriptor.
+ * Otherwise, it is a 0-based index into the WIM image's table of
+ * security descriptors (see: `struct wim_security_data') */
+ sle32 security_id;
+
+ /* Offset, in bytes, from the start of the uncompressed metadata
+ * resource of this directory's child directory entries, or 0 if this
+ * directory entry does not correspond to a directory or otherwise does
+ * not have any children. */
+ le64 subdir_offset;
+
+ /* Reserved fields */
+ le64 unused_1;
+ le64 unused_2;
+
+ /* Creation time, last access time, and last write time, in
+ * 100-nanosecond intervals since 12:00 a.m UTC January 1, 1601. They
+ * should correspond to the times gotten by calling GetFileTime() on
+ * Windows. */
+ le64 creation_time;
+ le64 last_access_time;
+ le64 last_write_time;
+
+ /* Vaguely, the SHA-1 message digest ("hash") of the file's contents.
+ * More specifically, this is for the "unnamed data stream" rather than
+ * any "alternate data streams". This hash value is used to look up the
+ * corresponding entry in the WIM's stream lookup table to actually find
+ * the file contents within the WIM.
+ *
+ * If the file has no unnamed data stream (e.g. is a directory), then
+ * this field will be all zeroes. If the unnamed data stream is empty
+ * (i.e. an "empty file"), then this field is also expected to be all
+ * zeroes. (It will be if wimlib created the WIM image, at least;
+ * otherwise it can't be ruled out that the SHA-1 message digest of 0
+ * bytes of data is given explicitly.)
+ *
+ * If the file has reparse data, then this field will instead specify
+ * the SHA-1 message digest of the reparse data. If it is somehow
+ * possible for a file to have both an unnamed data stream and reparse
+ * data, then this is not handled by wimlib.
+ *
+ * As a further special case, if this field is all zeroes but there is
+ * an alternate data stream entry with no name and a nonzero SHA-1
+ * message digest field, then that hash must be used instead of this
+ * one. In fact, when named data streams are present, some versions of
+ * Windows PE contain a bug where they only look in the alternate data
+ * stream entries for the unnamed data stream, not here.
+ */
+ u8 unnamed_stream_hash[SHA1_HASH_SIZE];
+
+ /* The format of the following data is not yet completely known and they
+ * do not correspond to Microsoft's documentation.
+ *
+ * If this directory entry is for a reparse point (has
+ * FILE_ATTRIBUTE_REPARSE_POINT set in the attributes field), then the
+ * version of the following fields containing the reparse tag is valid.
+ * Furthermore, the field notated as not_rpfixed, as far as I can tell,
+ * is supposed to be set to 1 if reparse point fixups (a.k.a. fixing the
+ * targets of absolute symbolic links) were *not* done, and otherwise 0.
+ *
+ * If this directory entry is not for a reparse point, then the version
+ * of the following fields containing the hard_link_group_id is valid.
+ * All MS says about this field is that "If this file is part of a hard
+ * link set, all the directory entries in the set will share the same
+ * value in this field.". However, more specifically I have observed
+ * the following:
+ * - If the file is part of a hard link set of size 1, then the
+ * hard_link_group_id should be set to either 0, which is treated
+ * specially as indicating "not hardlinked", or any unique value.
+ * - The specific nonzero values used to identity hard link sets do
+ * not matter, as long as they are unique.
+ * - However, due to bugs in Microsoft's software, it is actually NOT
+ * guaranteed that directory entries that share the same hard link
+ * group ID are actually hard linked to each either. See
+ * inode_fixup.c for the code that handles this.
+ */
+ union {
+ struct {
+ le32 rp_unknown_1;
+ le32 reparse_tag;
+ le16 rp_unknown_2;
+ le16 not_rpfixed;
+ } _packed_attribute reparse;
+ struct {
+ le32 rp_unknown_1;
+ le64 hard_link_group_id;
+ } _packed_attribute nonreparse;
+ };
+
+ /* Number of alternate data stream entries that directly follow this
+ * dentry on-disk. */
+ le16 num_alternate_data_streams;
+
+ /* If nonzero, this is the length, in bytes, of this dentry's UTF-16LE
+ * encoded short name (8.3 DOS-compatible name), excluding the null
+ * terminator. If zero, then the long name of this dentry does not have
+ * a corresponding short name (but this does not exclude the possibility
+ * that another dentry for the same file has a short name). */
+ le16 short_name_nbytes;
+
+ /* If nonzero, this is the length, in bytes, of this dentry's UTF-16LE
+ * encoded "long" name, excluding the null terminator. If zero, then
+ * this file has no long name. The root dentry should not have a long
+ * name, but all other dentries in the image should have long names. */
+ le16 file_name_nbytes;
+
+ /* Beginning of optional, variable-length fields */
+
+ /* If file_name_nbytes != 0, the next field will be the UTF-16LE encoded
+ * long file name. This will be null-terminated, so the size of this
+ * field will really be file_name_nbytes + 2. */
+ /*utf16lechar file_name[];*/
+
+ /* If short_name_nbytes != 0, the next field will be the UTF-16LE
+ * encoded short name. This will be null-terminated, so the size of
+ * this field will really be short_name_nbytes + 2. */
+ /*utf16lechar short_name[];*/
+
+ /* If there is still space in the dentry (according to the 'length'
+ * field) after 8-byte alignment, then the remaining space will be a
+ * variable-length list of tagged metadata items. See tagged_items.c
+ * for more information. */
+ /* u8 tagged_items[] _aligned_attribute(8); */
+
+} _packed_attribute;
+ /* If num_alternate_data_streams != 0, then there are that many
+ * alternate data stream entries following the dentry, on an 8-byte
+ * aligned boundary. They are not counted in the 'length' field of the
+ * dentry. */
+
+/* Calculate the minimum unaligned length, in bytes, of an on-disk WIM dentry
+ * that has names of the specified lengths. (Zero length means the
+ * corresponding name actually does not exist.) The returned value excludes
+ * tagged metadata items as well as any alternate data stream entries that may
+ * need to follow the dentry. */