+/*
+ * 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 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 lookup_table_entry *lte;
+ };
+
+ /* Length of stream name (UTF-16). This is in bytes, not characters,
+ * and does not include the terminating null character */
+ u16 stream_name_len;
+
+ /* Length of stream name (UTF-8) */
+ u16 stream_name_utf8_len;
+
+ /* Stream name (UTF-16) */
+ char *stream_name;
+
+ /* Stream name (UTF-8) */
+ char *stream_name_utf8;
+
+#ifdef WITH_FUSE
+ /* Number to identify an alternate data stream even after it's possibly
+ * been moved or renamed. */
+ u32 stream_id;
+#endif
+};
+
+
+static inline bool ads_entries_have_same_name(const struct ads_entry *entry_1,
+ const struct ads_entry *entry_2)
+{
+ if (entry_1->stream_name_len != entry_2->stream_name_len)
+ return false;
+ return memcmp(entry_1->stream_name, entry_2->stream_name,
+ entry_1->stream_name_len) == 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 field on the on-disk WIM dentry tells us 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. In-memory, we fix up this
+ * flaw by allocating a `struct 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 fix_inodes() in
+ * hardlink.c).
+ */