+ u8 verified : 1;
+
+ 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;
+
+ /* If the file is part of a hard link set, all the directory entries in
+ * the set will share the same value for this field.
+ *
+ * Unfortunately, in some WIMs it is NOT the case that all dentries that
+ * share this field are actually in the same hard link set, although the
+ * WIMs that wimlib writes maintain this restriction. */
+ u64 ino;
+
+ struct list_head dentry_list;
+ struct hlist_node hlist;
+ char *extracted_file;
+
+ struct dentry *children;
+
+#ifdef WITH_FUSE
+ u16 num_opened_fds;
+ u16 num_allocated_fds;
+ struct wimlib_fd **fds;
+ u32 next_stream_id;
+#endif
+};
+
+#define inode_for_each_dentry(dentry, inode) \
+ list_for_each_entry((dentry), &(inode)->dentry_list, inode_dentry_list)
+
+#define inode_add_dentry(dentry, inode) \
+ list_add(&(dentry)->inode_dentry_list, &(inode)->dentry_list)
+
+/*
+ * 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.
+ */