+
+ /* The format of the following data is not yet completely known and they
+ * do not correspond to Microsoft's documentation.
+ *
+ * If this directory entry is for a reparse point (has
+ * FILE_ATTRIBUTE_REPARSE_POINT set in the attributes field), then the
+ * version of the following fields containing the reparse tag is valid.
+ * Furthermore, the field notated as not_rpfixed, as far as I can tell,
+ * is supposed to be set to 1 if reparse point fixups (a.k.a. fixing the
+ * targets of absolute symbolic links) were done, and otherwise 0.
+ *
+ * If this directory entry is not for a reparse point, then the version
+ * of the following fields containing the hard_link_group_id is valid.
+ * All MS says about this field is that "If this file is part of a hard
+ * link set, all the directory entries in the set will share the same
+ * value in this field.". However, more specifically I have observed
+ * the following:
+ * - If the file is part of a hard link set of size 1, then the
+ * hard_link_group_id should be set to either 0, which is treated
+ * specially as indicating "not hardlinked", or any unique value.
+ * - The specific nonzero values used to identity hard link sets do
+ * not matter, as long as they are unique.
+ * - However, due to bugs in Microsoft's software, it is actually NOT
+ * guaranteed that directory entries that share the same hard link
+ * group ID are actually hard linked to each either. We have to
+ * handle this by using special code to use distinguishing features
+ * (possible because some information about the underlying inode is
+ * repeated in each dentry) to split up these fake hard link groups
+ * into what they actually are supposed to be.
+ */