Skip to content
This repository has been archived by the owner on Aug 11, 2022. It is now read-only.

link: can't relatively link another module multiple times #7579

Closed
jonathanong opened this issue Mar 9, 2015 · 3 comments
Closed

link: can't relatively link another module multiple times #7579

jonathanong opened this issue Mar 9, 2015 · 3 comments
Labels

Comments

@jonathanong
Copy link

ex. if i link to the same module multiple times with npm link ../standardberry, i'll get the following error:

npm ERR! Refusing to delete: /Users/jong/.nvm/versions/io.js/v1.5.0/bin/standardberry not in /Users/jong/Workspace/collect/collector
File exists: /Users/jong/.nvm/versions/io.js/v1.5.0/bin/standardberry
Move it away, and try again. 

thing is... it's the same file. i really should be doing npm link standardberry at this point, but sometimes i don't remember if i've linked a module or not.

solution would be to check whether the binaries point to the same location before actually erroring.

@smikes
Copy link
Contributor

smikes commented Mar 9, 2015

Thanks for the bug report.

This is a relatively new bug that was probably introduced when @othiym23 fixed a horrific problem where npm would sometimes vacuum up directories above the current node_modules. Anyway, npm is perhaps a little too conservative right now in what it deletes.

@othiym23
Copy link
Contributor

othiym23 commented Mar 9, 2015

This is a real and super annoying bug that bit me several times this weekend alone. It will get fixed soon. Thanks for filling the issue, @jonathanong!

othiym23 added a commit that referenced this issue Mar 11, 2015
Fixes #7579.

When npm removes a file or directory, it verifies whether the thing
being removed is under npm's control. This isn't something that can be
ascertained directly, so gentlyRm checks to see if there's a plausible
case that this file was something that was originally installed by npm.
Mostly it just verifies whether either the deletion target or the
parent directory (which could be passed in as the base, or could be the
prefix otherwise) is under one of the paths that npm might have reason
to mess with.

It will also deal with a certain amount of symbolic link trickery, but
this being done overly aggressively before, and now has been cleaned up
some.
@othiym23
Copy link
Contributor

The bug had been around for a while. I think it was more that most people weren't encountering it because the situations in which it bit were fairly specific. I gave gently-rm.js another thorough overhaul, and this time made sure that @iarna and I both understood the code before merging the changes. It's possible that we've overlooked some corner cases (gentlyRm relies on heuristics tied to assumptions about how people work with their packages that may not hold up in all cases), but it turns out that when it's overly cautious, it's been worth investigating why. Thanks for filing this, @jonathanong!

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

3 participants