Fall back to hard link when symlink creation lacks privilege

[rich-purnell]

📖 Description

When WinGet runs without administrator privileges or Developer Mode enabled, std::filesystem::create_symlink() fails with the error:

Error code: 1314 - create_symlink: A required privilege is not held by the client.

This happens because creating symbolic links requires the SeCreateSymbolicLinkPrivilege, which is only granted to administrators or available when Developer Mode is turned on. While WinGet typically runs with those privileges, there are scenarios where they are not held — for example, when running as a standard user or in a restricted environment.

I wrote a local test program that confirmed this behavior. Under those conditions, std::filesystem::create_symlink(target, link) fails with the above error, but std::filesystem::create_hard_link(target, link) succeeds. Since a hard link provides identical file resolution behavior for this use case (pointing to the same file on disk), it is a viable fallback.

This change adds a fallback: when symlink creation fails specifically with ERROR_PRIVILEGE_NOT_HELD, the code attempts a hard link instead before returning false.

Such a change may not solve all problems (for example, in some special file system structures), but it can reduce the impact scope.

🔗 References

Resolves #6058

🔍 Validation

Build succeeds with no errors or warnings.

✅ Checklist

• Signed the Contributor License Agreement
• Linked to an issue
• Updated Release Notes (if applicable)
• Updated documentation (if applicable)
• Updated Copilot instructions (if build, architecture, or conventions changed)

📋 Issue Type

• Bug fix
• Feature
• Task

Microsoft Reviewers: Open in CodeFlow

[rich-purnell]

@microsoft-github-policy-service agree

[Trenly]

The uninstall flow may need to account for hard links with this change. Tests should be added to validate hardlink creation, path resolution, and removal.

What happens in the upgrade scenario where a hardlink exists but the user now has symlink permissions - does it stay a hardlink, or should it be replaced with a symlink?

[rich-purnell]

The uninstall flow may need to account for hard links with this change. Tests should be added to validate hardlink creation, path resolution, and removal.

What happens in the upgrade scenario where a hardlink exists but the user now has symlink permissions - does it stay a hardlink, or should it be replaced with a symlink?

I see that in the current installation flow, before creating a symlink, std::filesystem::remove(filePath) is called to remove the existing symlink. My testing shows that it also correctly removes hard links. So when a user gains permissions, reinstallation will remove the hard link and then create a symlink. I did overlook the uninstall part – I will check it later. Regarding adding new tests, since this is my first time working on this project, I need some time to understand which scenarios are already covered by the existing tests.