X-Git-Url: https://wimlib.net/git/?a=blobdiff_plain;f=include%2Fwimlib%2Fdentry.h;h=40a4c8e67d7e259a5be7a69a2dd2e5a6dc63fa71;hb=88e2f555ab11c237a87a1928df67d96ae235209d;hp=241dc56d58c47493b059cc1926b936c21ffabe78;hpb=3de1ec66f778edda19865482d685bc6f4e17faf7;p=wimlib

diff --git a/include/wimlib/dentry.h b/include/wimlib/dentry.h
index 241dc56d..40a4c8e6 100644
--- a/include/wimlib/dentry.h
+++ b/include/wimlib/dentry.h
@@ -21,28 +21,18 @@ struct blob_table;
  * 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 an 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).
+ * links, it's possible for an 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 inode_fixup.c.)
+ * information, such as file attributes, the security descriptor, and 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.
+ * (See dentry_tree_fix_inodes().)
  */
 struct wim_dentry {
 	/* Pointer to the inode for this dentry.  This will contain some
@@ -231,13 +221,12 @@ extern tchar *
 dentry_full_path(struct wim_dentry *dentry);
 
 extern int
-new_dentry(const tchar *name, struct wim_dentry **dentry_ret);
-
-extern int
-new_dentry_with_inode(const tchar *name, struct wim_dentry **dentry_ret);
+new_dentry_with_new_inode(const tchar *name, bool set_timestamps,
+			  struct wim_dentry **dentry_ret);
 
 extern int
-new_dentry_with_timeless_inode(const tchar *name, struct wim_dentry **dentry_ret);
+new_dentry_with_existing_inode(const tchar *name, struct wim_inode *inode,
+			       struct wim_dentry **dentry_ret);
 
 extern void
 dentry_tree_clear_inode_visited(struct wim_dentry *root);