Feat/windows junction support

[ChanTsune]

No description provided.

[coderabbitai]

Important

Review skipped

Draft detected.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 6f4eda91-3c93-4dc8-b005-fdaf16c4367e

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch feat/windows-junction-support

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[gemini-code-assist]

Code Review

This pull request introduces support for Windows NTFS junctions, enabling them to be detected during archive creation and restored during extraction. Junctions are represented using the PNA encoding for hard links with a directory target type. The implementation includes new Windows-specific utilities for reparse point manipulation and updates to the CLI's path editing and extraction logic. Review feedback identified a bug in the junction creation logic involving incorrect NT namespace prefixing and an invalid string literal, as well as a potential extraction failure when canonicalizing targets that do not yet exist.

[gemini-code-assist]

The target path provided to create_junction may come from std::fs::canonicalize, which on Windows prepends the verbatim prefix \\?\. If this prefix is present, prepending \??\ results in an invalid NT namespace path like \??\\\?\C:\.... Additionally, the raw string literal r"\??\" used in the original code is invalid in Rust because raw strings cannot end with an odd number of backslashes.

You should strip the \\?\ prefix (if present) from the target path and use a valid string literal for the NT prefix.

Suggested change

	let mut subst_wide: Vec<u16> = r"\??\".encode_utf16().collect();
	subst_wide.extend(target.as_os_str().encode_wide());
	let print_wide: Vec<u16> = target.as_os_str().encode_wide().collect();
	let mut target_wide: Vec<u16> = target.as_os_str().encode_wide().collect();
	if target_wide.starts_with(&[92, 92, 63, 92]) {
	target_wide.drain(0..4);
	}
	let mut subst_wide: Vec<u16> = "\\??\\".encode_utf16().collect();
	subst_wide.extend(&target_wide);
	let print_wide = target_wide;

[gemini-code-assist]

Using std::fs::canonicalize here will fail if the junction target does not yet exist on disk, which is common when extracting an archive containing both a directory and a junction pointing to it. If canonicalize fails, the code falls back to joined, which might be a relative path. However, create_junction (in reparse.rs) explicitly rejects relative targets.

Consider using std::path::absolute to ensure the path is absolute without requiring it to exist on disk, while still attempting canonicalize for a cleaner path if possible.

            let absolute = std::path::absolute(&joined).unwrap_or_else(|_| joined.clone());
            match std::fs::canonicalize(&absolute) {
                Ok(canon) => canon,
                Err(e) => {
                    log::debug!(
                        "Failed to canonicalize junction target {}: {}; using absolute path",
                        absolute.display(),
                        e
                    );
                    absolute
                }
            }