Close the file descriptor if exiting upload via an error. #80
Conversation
This file contains 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
This fixes https://npm.community/t/unhelpful-error-message-when-publishing-without-logging-in-error-eperm-operation-not-permitted-unlink/1377/3 and the other dozen or so issues that that link references, and possibly many more involving poor error messages from errors thrown by the upload function. @zkat you mentioned you could take a look at any fixes / answer any questions, if you could look this over and let me know if this is a good / valid approach that would be fantastic, thanks! (it wasn't a race condition, luckily :P). it may also be helpful to add something like ``` if (!auth.token || !(auth.username && auth.password)) { log.warn('publish', 'not logged in') } ``` just before we even open the first file descriptor to make sure that even if the error message is completely wrong something in the log will give users a clue what may be going on. I took the method of looking for login creds from the logout method, I'm not sure that's valid or if alternatives to npm exist that don't require credentials but users could still publish to. Triage of the issue: 1. The upload function throws an error 2. As that error bubbles through [cacache](https://www.npmjs.com/package/cacache#with-tmp) it tries to delete the tmpdir as it should 3. It can't delete the temp dir as the upload function's readFileStream to the tar it was trying to upload is still open. 4. [cacache](https://www.npmjs.com/package/cacache#with-tmp) throws an error about it's inability to remove the dir, which suppresses the upload function's error.
zkat
pushed a commit
that referenced
this pull request
Dec 10, 2018
This fixes https://npm.community/t/unhelpful-error-message-when-publishing-without-logging-in-error-eperm-operation-not-permitted-unlink/1377/3 and the other dozen or so issues that that link references, and possibly many more involving poor error messages from errors thrown by the upload function. @zkat you mentioned you could take a look at any fixes / answer any questions, if you could look this over and let me know if this is a good / valid approach that would be fantastic, thanks! (it wasn't a race condition, luckily :P). it may also be helpful to add something like ``` if (!auth.token || !(auth.username && auth.password)) { log.warn('publish', 'not logged in') } ``` just before we even open the first file descriptor to make sure that even if the error message is completely wrong something in the log will give users a clue what may be going on. I took the method of looking for login creds from the logout method, I'm not sure that's valid or if alternatives to npm exist that don't require credentials but users could still publish to. Triage of the issue: 1. The upload function throws an error 2. As that error bubbles through [cacache](https://www.npmjs.com/package/cacache#with-tmp) it tries to delete the tmpdir as it should 3. It can't delete the temp dir as the upload function's readFileStream to the tar it was trying to upload is still open. 4. [cacache](https://www.npmjs.com/package/cacache#with-tmp) throws an error about it's inability to remove the dir, which suppresses the upload function's error. Fixes: https://npm.community/t/unhelpful-error-message-when-publishing-without-logging-in-error-eperm-operation-not-permitted-unlink/1377/3 PR-URL: #80 Credit: @macdja38 Reviewed-By: @zkat
antongolub
pushed a commit
to antongolub-forks/npm-cli
that referenced
this pull request
May 18, 2024
`linkGently` would return true if a link target had been visited before. `linkBin` would then chmod the link `to`, regardless of whether this file exists. This causes `npm install` to fail if multiple packages link to a non-existent bin with the same name. By returning false in `linkGently`, `linkBin` no skips the chmod on the non-existent file. ## References Fixes npm#4597
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.
This fixes https://npm.community/t/unhelpful-error-message-when-publishing-without-logging-in-error-eperm-operation-not-permitted-unlink/1377/3 and the other dozen or so issues that that link references, and possibly many more involving poor error messages from errors thrown by the upload function.
@zkat you mentioned you could take a look at any fixes / answer any questions, if you could look this over and let me know if this is a good / valid approach that would be fantastic, thanks! (it wasn't a race condition, luckily :P).
it may also be helpful to add something like
just before we even open the first file descriptor to make sure that even if the error message is completely wrong something in the log will give users a clue what may be going on. I took the method of looking for login creds from the logout method, I'm not sure that's valid or if alternatives to npm exist that don't require credentials but users could still publish to.
Triage of the issue: