- /* Timestamps for the dentry. 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;
-
- /* %true iff the dentry's lookup table entry 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;
-
- /* 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;
-
- /* 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;
-
- /* 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 link_group_id;
-
- /* Number of alternate data streams associated with this file. */
- u16 num_ads;
-