+struct inode {
+ /* Timestamps for the inode. The timestamps are the number of
+ * 100-nanosecond intervals that have elapsed since 12:00 A.M., January
+ * 1st, 1601, UTC. This is the same format used in NTFS inodes. */
+ u64 creation_time;
+ u64 last_access_time;
+ u64 last_write_time;
+
+ /* The file attributes associated with this inode. This is a bitwise OR
+ * of the FILE_ATTRIBUTE_* flags. */
+ u32 attributes;
+
+ /* The index of the security descriptor in the WIM image's table of
+ * security descriptors that contains this file's security information.
+ * If -1, no security information exists for this file. */
+ int32_t security_id;
+
+ /* %true iff the inode's lookup table entries has been resolved (i.e.
+ * the @lte field is valid, but the @hash field is not valid)
+ *
+ * (This is not an on-disk field.) */
+ bool resolved;
+
+ u16 num_ads;
+
+ /* A hash of the file's contents, or a pointer to the lookup table entry
+ * for this dentry if the lookup table entries have been resolved.
+ *
+ * More specifically, this is for the un-named default file stream, as
+ * opposed to the alternate (named) file streams, which may have their
+ * own lookup table entries. */
+ union {
+ u8 hash[SHA1_HASH_SIZE];
+ struct lookup_table_entry *lte;
+ };
+
+ /* Identity of a reparse point. See
+ * http://msdn.microsoft.com/en-us/library/windows/desktop/aa365503(v=vs.85).aspx
+ * for what a reparse point is. */
+ u32 reparse_tag;
+
+ u32 link_count;
+
+ struct ads_entry **ads_entries;
+
+ u64 ino;
+
+ struct list_head dentry_list;
+ union {
+ struct stream_list_head lte_group_list;
+ struct hlist_node hlist;
+ };
+ char *extracted_file;
+};
+
+/*
+ * In-memory structure for a WIM directory entry (dentry). There is a directory
+ * tree for each image in the WIM.
+ *
+ * Please note that this is a directory entry and not an inode. Since NTFS
+ * allows hard links, it's possible for a NTFS inode to correspond to multiple
+ * WIM dentries. The @hard_link field tells you the number of the NTFS inode
+ * that the dentry corresponds to.
+ *
+ * Unfortunately, WIM files do not have an analogue to an inode; instead certain
+ * information, such as file attributes, the security descriptor, and file
+ * streams is replicated in each hard-linked dentry, even though this
+ * information really is associated with an inode.
+ *
+ * Confusingly, it's also possible for stream information to be missing from a
+ * dentry in a hard link set, in which case the stream information needs to be
+ * gotten from one of the other dentries in the hard link set. In addition, it
+ * is possible for dentries to have inconsistent security IDs, file attributes,
+ * or file streams when they share the same hard link ID (don't even ask. I
+ * hope that Microsoft may have fixed this problem, since I've only noticed it
+ * in the 'install.wim' for Windows 7). For those dentries, we have to use the
+ * conflicting fields to split up the hard link groups.
+ */