-/*
- * 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.
- */
-struct dentry {
- /* The inode for this dentry */
- struct inode *inode;
-
- /* The parent of this directory entry. */
- struct dentry *parent;
-
- /* Linked list of sibling directory entries. */
- struct dentry *next;
- struct dentry *prev;
-
- /*
- * Size of directory entry on disk, in bytes. Typical size is around
- * 104 to 120 bytes.
- *
- * It is possible for the length 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.
- *
- * The length here includes the base directory entry on disk as well as
- * the long and short filenames. It does NOT include any alternate
- * stream entries that may follow the directory entry, even though the
- * size of those needs to be considered. The length SHOULD be 8-byte
- * aligned, although we don't require it to be. We do require the
- * length to be large enough to hold the file name(s) of the dentry;
- * additionally, a warning is issued if this field is larger than the
- * aligned size.
- */
- u64 length;
-
-
- /* The offset, from the start of the uncompressed WIM metadata resource
- * for this image, of this dentry's child dentries. 0 if the directory
- * entry has no children, which is the case for regular files or reparse
- * points. */
- u64 subdir_offset;
-
-
- /* Although M$'s documentation does not tell you this, it seems that the
- * reparse_reserved field does not actually exist. So the hard_link
- * field directly follows the reparse_tag on disk. EXCEPT when the
- * dentry is actually a reparse point... well, just take a look at the
- * read_dentry() function. */
- //u32 reparse_reserved;
-
-
- /* Length of short filename, in bytes, not including the terminating
- * zero wide-character. */
- u16 short_name_len;
-
- /* Length of file name, in bytes, not including the terminating zero
- * wide-character. */
- u16 file_name_len;
-
- /* Length of the filename converted into UTF-8, in bytes, not including
- * the terminating zero byte. */
- u16 file_name_utf8_len;
-
- /* Pointer to the short filename (malloc()ed buffer) */
- char *short_name;
-
- /* Pointer to the filename (malloc()ed buffer). */
- char *file_name;
-
- /* Pointer to the filename converted to UTF-8 (malloc()ed buffer). */
- char *file_name_utf8;
-
- /* Full path to this dentry (malloc()ed buffer). */
- char *full_path_utf8;
- u32 full_path_utf8_len;
-
- /* Number of references to the dentry tree itself, as in multiple
- * WIMStructs */
- u32 refcnt;
-
- /* List of dentries in the hard link set */
- struct list_head inode_dentry_list;
- union {
- struct list_head tmp_list;
- bool is_extracted;
- };
-};
-