+struct stat;
+struct wim_lookup_table;
+struct WIMStruct;
+struct wim_lookup_table_entry;
+struct wimfs_fd;
+struct wim_inode;
+struct wim_dentry;
+
+/* Size of the struct wim_dentry up to and including the file_name_len. */
+#define WIM_DENTRY_DISK_SIZE 102
+
+/* Size of on-disk WIM alternate data stream entry, in bytes, up to and
+ * including the stream length field (see below). */
+#define WIM_ADS_ENTRY_DISK_SIZE 38
+
+/*
+ * Reparse tags documented at
+ * http://msdn.microsoft.com/en-us/library/dd541667(v=prot.10).aspx
+ */
+#define WIM_IO_REPARSE_TAG_RESERVED_ZERO 0x00000000
+#define WIM_IO_REPARSE_TAG_RESERVED_ONE 0x00000001
+#define WIM_IO_REPARSE_TAG_MOUNT_POINT 0xA0000003
+#define WIM_IO_REPARSE_TAG_HSM 0xC0000004
+#define WIM_IO_REPARSE_TAG_HSM2 0x80000006
+#define WIM_IO_REPARSE_TAG_DRIVER_EXTENDER 0x80000005
+#define WIM_IO_REPARSE_TAG_SIS 0x80000007
+#define WIM_IO_REPARSE_TAG_DFS 0x8000000A
+#define WIM_IO_REPARSE_TAG_DFSR 0x80000012
+#define WIM_IO_REPARSE_TAG_FILTER_MANAGER 0x8000000B
+#define WIM_IO_REPARSE_TAG_SYMLINK 0xA000000C
+
+#define FILE_ATTRIBUTE_READONLY 0x00000001
+#define FILE_ATTRIBUTE_HIDDEN 0x00000002
+#define FILE_ATTRIBUTE_SYSTEM 0x00000004
+#define FILE_ATTRIBUTE_DIRECTORY 0x00000010
+#define FILE_ATTRIBUTE_ARCHIVE 0x00000020
+#define FILE_ATTRIBUTE_DEVICE 0x00000040
+#define FILE_ATTRIBUTE_NORMAL 0x00000080
+#define FILE_ATTRIBUTE_TEMPORARY 0x00000100
+#define FILE_ATTRIBUTE_SPARSE_FILE 0x00000200
+#define FILE_ATTRIBUTE_REPARSE_POINT 0x00000400
+#define FILE_ATTRIBUTE_COMPRESSED 0x00000800
+#define FILE_ATTRIBUTE_OFFLINE 0x00001000
+#define FILE_ATTRIBUTE_NOT_CONTENT_INDEXED 0x00002000
+#define FILE_ATTRIBUTE_ENCRYPTED 0x00004000
+#define FILE_ATTRIBUTE_VIRTUAL 0x00010000
+
+
+/* Alternate data stream entry.
+ *
+ * We read this from disk in the read_ads_entries() function; see that function
+ * for more explanation. */
+struct wim_ads_entry {
+ union {
+ /* SHA-1 message digest of stream contents */
+ u8 hash[SHA1_HASH_SIZE];
+
+ /* The corresponding lookup table entry (only for resolved
+ * streams) */
+ struct wim_lookup_table_entry *lte;
+ };
+
+ /* Length of UTF16-encoded stream name, in bytes, not including the
+ * terminating null character. */
+ u16 stream_name_nbytes;
+
+ /* Stream name (UTF-16LE) */
+ utf16lechar *stream_name;
+
+ /* Number to identify an alternate data stream even after it's possibly
+ * been moved or renamed. */
+ u32 stream_id;
+};
+
+
+static inline bool
+ads_entries_have_same_name(const struct wim_ads_entry *entry_1,
+ const struct wim_ads_entry *entry_2)
+{
+ return entry_1->stream_name_nbytes == entry_2->stream_name_nbytes &&
+ memcmp(entry_1->stream_name, entry_2->stream_name,
+ entry_1->stream_name_nbytes) == 0;
+}
+
+/*
+ * In-memory structure for a WIM directory entry (dentry). There is a directory
+ * tree for each image in the WIM.
+ *
+ * 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 group ID field of the on-disk WIM dentry tells us the number of
+ * the NTFS inode that the dentry corresponds to (and this gets placed in
+ * d_inode->i_ino).
+ *
+ * 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. In-memory, we fix up this
+ * flaw by allocating a `struct wim_inode' for each dentry that contains some of
+ * this duplicated information, then combining the inodes for each hard link
+ * group together.
+ *
+ * Confusingly, it's 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. (See
+ * dentry_tree_fix_inodes() in hardlink.c).
+ */
+struct wim_dentry {
+ /* The inode for this dentry */
+ struct wim_inode *d_inode;
+
+ /* Red-black tree of sibling dentries */
+ struct rb_node rb_node;
+
+ /* Length of UTF-16LE encoded short filename, in bytes, not including
+ * the terminating zero wide-character. */
+ u16 short_name_nbytes;
+
+ /* Length of UTF-16LE encoded "long" file name, in bytes, not including
+ * the terminating null character. */
+ u16 file_name_nbytes;
+
+ /* Length of full path name encoded using "tchars", in bytes, not
+ * including the terminating null character. */
+ u32 full_path_nbytes;
+
+ /* Has this dentry been extracted yet? */
+ u8 is_extracted : 1;