installation: Windows hard link for plugin shims, then symlink (EvalSymlinks fallback)#904
installation: Windows hard link for plugin shims, then symlink (EvalSymlinks fallback)#904carterpewpew wants to merge 2 commits into
Conversation
Extract createSymlink() into build-tagged files (symlink_unix.go, symlink_windows.go) to isolate platform-specific symlink logic. On Windows, this enables elevated-privilege symlink creation with fallback to directory junctions. Add comprehensive symlink tests covering creation, target verification via os.Readlink/filepath.EvalSymlinks, platform-level path resolution, and dangling symlink behavior on Unix. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Add Test_reproduce_oldCodePath_osSymlink_unresolved to demonstrate that os.Symlink stores raw unresolved paths (e.g., /var/folders/... on macOS) while createSymlink correctly resolves platform symlinks first. The test confirms the bug in the old code path and verifies the fix. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: carterpewpew The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
One or more co-authors of this pull request were not found. You must specify co-authors in commit message trailer via: Supported
Alternatively, if the co-author should not be included, remove the Please update your commit message(s) by doing |
|
Welcome @carterpewpew! |
|
Sorry, accidentally opened, please ignore |
|
Looks promising, especially if you could figure out how not to break existing installations that already installed some plugins via symlinks (it should work, right?). Thanks for taking this on. |
[WIP]
What this PR does
On Windows, creating plugin shims in .krew/bin no longer depends only on os.Symlink. The code tries os.Link first (same volume, no extra symlink privilege in the common case), then falls back to os.Symlink. The source path is passed through filepath.EvalSymlinks before the symlink path so the fallback does not use an unresolved path if the install path goes through a junction or directory symlink.
Uninstall and upgrades use removeLink with an isLink helper on Windows that also allows removing hard-linked bin entries, not only symlinks.
On non-Windows, behavior is unchanged: createSymlink is a plain os.Symlink and isLink is symlink-only, matching the old logic.
Fixes #886