Skip to content

Commit

Permalink
fix: unlink symlinks before copying git hooks
Browse files Browse the repository at this point in the history
there was an issue where if a git hook with the same name existed
already, but was a symlink, ka-clone would overrwrite the link
destination’s contents rather than replacing the symlink!  apparently
this is what python’s `shutil.copyfile` does by design.

as a fix, manually unlink any symlinks first to be extra safe, then use
`shutil.copy` instead.

#devenvfixup

Auditors: csilvers, ethan, mopewa
  • Loading branch information
Matthew Rothenberg committed Jun 30, 2015
1 parent 183fa61 commit b5d21b0
Showing 1 changed file with 4 additions and 1 deletion.
5 changes: 4 additions & 1 deletion bin/ka-clone
Original file line number Diff line number Diff line change
Expand Up @@ -124,7 +124,10 @@ def _install_git_hook(template_name, hook_name):
if not os.path.isdir(hooks_dir):
os.makedirs(hooks_dir)
dst = os.path.join(hooks_dir, hook_name)
shutil.copyfile(src, dst)
# if dst is a symlink, unlink (remove) it first, to avoid overwriting
if os.path.islink(dst):
os.unlink(dst)
shutil.copy(src, dst)
os.chmod(dst, (os.stat(dst)).st_mode | 0111) # ensure chmod +x


Expand Down

1 comment on commit b5d21b0

@mroth
Copy link
Contributor

@mroth mroth commented on b5d21b0 Jul 6, 2015

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In certain cases for users upgrading from older versions of khan-dotfiles where the git template had a symlink directly into khan-linter, there was an edge case where this could lead to ka-clone overwriting the contents of khan-linter's githook.py, which then strangely causes the confusing _ka-commit-lint: fork: Resource temporarily unavailable error experienced by a few devs.

For people who find themselves in this situation, the absolute easiest fix is to entirely delete the devtools/khan-linter and devtools/ka-clone directories and then rerun setup.sh in khan-dotfiles, which will obtain fresh copies and then automatically repair the repositories. (If affecting a repository not handled by dotfiles, after the above steps are taken one can run ka-clone --repair manually in the effected repository)

Gotta love it when one line of code can cause a cascading issue across three different repositories!

Please sign in to comment.