- if (inode_1->i_num_ads != inode_2->i_num_ads)
- return false;
-
- for (u32 i = 0; i <= inode_1->i_num_ads; i++) {
- const u8 *hash_1 = inode_stream_hash_unresolved(inode_1, i);
- const u8 *hash_2 = inode_stream_hash_unresolved(inode_2, i);
-
- if (!hashes_equal(hash_1, hash_2) && !is_zero_hash(hash_1))
- return false;
-
- if (i && !ads_entries_have_same_name(&inode_1->i_ads_entries[i - 1],
- &inode_2->i_ads_entries[i - 1]))
- return false;
- }
-
- if (inode_1->i_attributes != inode_2->i_attributes)
- return false;
-
- if (inode_1->i_security_id != inode_2->i_security_id)
- return false;
-
- return true;
+ /* This certainly isn't the only thing we need to check to make sure the
+ * inodes are consistent. However, this seems to be the only thing that
+ * the MS implementation checks when working around its own bug.
+ *
+ * (Tested: If two dentries share the same hard link group ID, Windows
+ * 8.1 DISM will link them if they have the same unnamed stream hash,
+ * even if the dentries provide different timestamps, attributes,
+ * alternate data streams, and security IDs! And the one that gets used
+ * will change if you merely swap the filenames. But if you use
+ * different unnamed stream hashes with everything else the same, it
+ * doesn't link the dentries.)
+ *
+ * For non-buggy WIMs this function will always return true. */
+ return hashes_equal(inode_get_hash_of_unnamed_data_stream(inode_1),
+ inode_get_hash_of_unnamed_data_stream(inode_2));