Repository navigation
fix(runner): relink a deployed symlink that no longer points at its source - #54
Merged
Merged
Conversation
…ource A module whose checksums all match was skipped before deployFiles ran, so its "symlink points to wrong location" repair never fired. An install run from a temporary worktree that was later deleted left ~/.config/zsh/aliases.zsh, functions.zsh and ~/.gitmessage dangling, and every later run from ~/.dotfiles skipped zsh/git as up-to-date. The zsh verify.sh passed too: [[ -L ]] is true for a dangling link. shouldRunModule now returns ExecutionUpdateModule when a symlink-type destination is a symlink to anything but its source (dangling included). A missing or non-symlink destination is left as before. zsh verify.sh counts a dangling aliases.zsh / functions.zsh as an error. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
A module whose checksums all match is skipped before
deployFilesruns, soshouldDeployFile's "symlink points to wrong location" repair never fires. The checksums hash content, not where the links point.Seen on gov: the yazi/lazygit canary (#53) installed from
~/workspace/dotfiles-worktrees/main, and that worktree was later removed.~/.config/zsh/aliases.zsh,functions.zshand~/.gitmessagewere left dangling..zshrcsources them only-f, sol,..,mkcd,extractand the rest disappeared without an error. Re-running from~/.dotfileswouldn't repair them, because zsh/git were skipped as up-to-date. zshverify.shpassed too:[[ -L ]]is true for a dangling link.Fix
shouldRunModule: before returning Skip,staleSymlinkDestchecks eachtype: symlinkfile. If the dest is a symlink to anything other than its source (dangling included), it returnsExecutionUpdateModuleanddeployFilesrelinks it. A dest that is missing or is no longer a symlink is left as before.modules/zsh/verify.sh: a danglingaliases.zsh/functions.zshcounts as an error.Notes
verify.shchanges the zsh module checksum, so every host re-runs zsh once after this is pinned. That's expected.~/.dotfiles, then worktree). That is the intended self-heal.Testing
TestShouldRunModuleStaleSymlinkcovers correct link, dangling link, link to another file, and absent dest. It fails without the change.go test -race ./...,go vet, andshellcheck modules/zsh/verify.shpass.🤖 Generated with Claude Code