+
+ if (parse_link_reparse_point(rpbuf, *rpbuflen_p, &link)) {
+ /* Couldn't understand the reparse data; don't do the fixup. */
+ return 0;
+ }
+
+ /*
+ * Don't do reparse point fixups on relative symbolic links.
+ *
+ * On Windows, a relative symbolic link is supposed to be identifiable
+ * by having reparse tag WIM_IO_REPARSE_TAG_SYMLINK and flags
+ * SYMBOLIC_LINK_RELATIVE. We will use this information, although this
+ * may not always do what the user expects, since drive-relative
+ * symbolic links such as "\Users\Public" have SYMBOLIC_LINK_RELATIVE
+ * set, in addition to truely relative symbolic links such as "Users" or
+ * "Users\Public". However, WIMGAPI (as of Windows 8.1) has this same
+ * behavior.
+ *
+ * Otherwise, as far as I can tell, the targets of symbolic links that
+ * are NOT relative, as well as junctions (note: a mountpoint is the
+ * sames thing as a junction), must be NT namespace paths, for example:
+ *
+ * - \??\e:\Users\Public
+ * - \DosDevices\e:\Users\Public
+ * - \Device\HardDiskVolume4\Users\Public
+ * - \??\Volume{c47cb07c-946e-4155-b8f7-052e9cec7628}\Users\Public
+ * - \DosDevices\Volume{c47cb07c-946e-4155-b8f7-052e9cec7628}\Users\Public
+ */
+ if (link_is_relative_symlink(&link))
+ return 0;
+
+ rel_target = winnt_relativize_link_target(link.substitute_name,
+ link.substitute_name_nbytes,
+ params->capture_root_ino,
+ params->capture_root_dev);
+
+ if (rel_target == link.substitute_name) {
+ /* Target points outside of the tree being captured or had an
+ * unrecognized path format. Don't adjust it. */
+ return winnt_rpfix_progress(params, path, &link,
+ WIMLIB_SCAN_DENTRY_NOT_FIXED_SYMLINK);
+ }
+
+ /* We have an absolute target pointing within the directory being
+ * captured. @rel_target is the suffix of the link target that is the
+ * part relative to the directory being captured.
+ *
+ * We will cut off the prefix before this part (which is the path to the
+ * directory being captured) and add a dummy prefix. Since the process
+ * will need to be reversed when applying the image, it doesn't matter
+ * what exactly the prefix is, as long as it looks like an absolute
+ * path. */
+
+ static const wchar_t prefix[6] = L"\\??\\X:";
+ static const size_t num_unprintable_chars = 4;
+
+ size_t rel_target_nbytes =
+ link.substitute_name_nbytes - ((const u8 *)rel_target -
+ (const u8 *)link.substitute_name);
+
+ wchar_t tmp[(sizeof(prefix) + rel_target_nbytes) / sizeof(wchar_t)];
+
+ memcpy(tmp, prefix, sizeof(prefix));
+ memcpy(tmp + ARRAY_LEN(prefix), rel_target, rel_target_nbytes);
+
+ link.substitute_name = tmp;
+ link.substitute_name_nbytes = sizeof(tmp);
+
+ link.print_name = link.substitute_name + num_unprintable_chars;
+ link.print_name_nbytes = link.substitute_name_nbytes -
+ (num_unprintable_chars * sizeof(wchar_t));
+
+ if (make_link_reparse_point(&link, rpbuf, rpbuflen_p))
+ return 0;
+
+ ret = winnt_rpfix_progress(params, path, &link,
+ WIMLIB_SCAN_DENTRY_FIXED_SYMLINK);
+ if (ret)
+ return ret;
+ return RP_FIXED;
+}
+
+/* Load the reparse data of a file into the corresponding WIM inode. If the
+ * reparse point is a symbolic link or junction with an absolute target and
+ * RPFIX mode is enabled, then also rewrite its target to be relative to the
+ * capture root. */
+static noinline_for_stack int
+winnt_load_reparse_data(HANDLE h, struct wim_inode *inode,
+ const wchar_t *full_path, struct capture_params *params)
+{
+ struct reparse_buffer_disk rpbuf;
+ DWORD bytes_returned;