Fix dSYM uplifting when symlink is broken #7268
Merged
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
|
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @nrc (or someone else) soon. If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes. Please see the contribution instructions for more information. |
rust-highfive
added
the
S-waiting-on-review
We were sporadically but persistently seeing errors like
failed to link or copy `.../target/debugs/deps/bin-264030cd6c8a02be.dSYM` to `.../target/debug/bin.dSYM`
Caused by:
the source path is not an existing regular file
while running `cargo build`. Once the error occurs once, `cargo build`
will fail forever with the same error until `target/debug/bin.dSYM` is
manually unlinked.
After some investigation, I've determined that this situation arises
when the target of `bin.dSYM` goes missing. For example, if bin.dSYM is
pointing at `deps/bin-86908f0fa7f1440e.dSYM`, and
`deps/bin-86908f0fa7f1440e.dSYM` does not exist, then this error will
occur. I'm still not clear on why the underlying dSYM bundle
sporadically goes missing--perhaps it's the result of pressing Ctrl-C at
the wrong moment?--but Cargo should at least be able to handle this
situation better.
It turns out that Cargo was getting confused by the broken symlink. When
it goes to install the new `target/debug/bin.dSYM` link, it will remove
the existing `target/debug/bin.dSYM` file, if it exists. Unfortunately,
Cargo was checking whether the *target* of that symlink existed (e.g.,
`deps/bin-86908f0fa7f1440e.dSYM`, which in the buggy case would not
exist), rather than the symlink itself, deciding that there was no
existing symlink to remove, and crashing with EEXIST when trying to
install the new symlink.
This commit adjusts the existence check to evaluate whether the symlink
itself exists, rather than its target.
Note that while the symptoms are the same as rust-lang#4671, the root cause is
unrelated.
benesch
force-pushed
the
dsym-uplifting
branch
from
2924763 to
b03eeda
Compare
|
@bors: r+ Nice! |
|
📌 Commit b03eeda has been approved by |
bors
added
S-waiting-on-bors
bors
added a commit
that referenced
this pull request
Aug 20, 2019
Fix dSYM uplifting when symlink is broken
We were sporadically but persistently seeing errors like
failed to link or copy `.../target/debugs/deps/bin-264030cd6c8a02be.dSYM` to `.../target/debug/bin.dSYM`
Caused by:
the source path is not an existing regular file
while running `cargo build`. Once the error occurs once, `cargo build`
will fail forever with the same error until `target/debug/bin.dSYM` is
manually unlinked.
After some investigation, I've determined that this situation arises
when the target of `bin.dSYM` goes missing. For example, if bin.dSYM is
pointing at `deps/bin-86908f0fa7f1440e.dSYM`, and
`deps/bin-86908f0fa7f1440e.dSYM` does not exist, then this error will
occur. I'm still not clear on why the underlying dSYM bundle
sporadically goes missing--perhaps it's the result of pressing Ctrl-C at
the wrong moment?--but Cargo should at least be able to handle this
situation better.
It turns out that Cargo was getting confused by the broken symlink. When
it goes to install the new `target/debug/bin.dSYM` link, it will remove
the existing `target/debug/bin.dSYM` file, if it exists. Unfortunately,
Cargo was checking whether the *target* of that symlink existed (e.g.,
`deps/bin-86908f0fa7f1440e.dSYM`, which in the buggy case would not
exist), rather than the symlink itself, deciding that there was no
existing symlink to remove, and crashing with EEXIST when trying to
install the new symlink.
This commit adjusts the existence check to evaluate whether the symlink
itself exists, rather than its target.
Note that while the symptoms are the same as #4671, the root cause is
unrelated.
|
☀️ Test successful - checks-azure |
|
Woo, thanks @alexcrichton! |
bors
added a commit
to rust-lang/rust
that referenced
this pull request
Aug 27, 2019
Update cargo Update cargo 10 commits in 3f700ec43ce72305eb5315cfc710681f3469d4b4..22f7dd0495cd72ce2082d318d5a9b4dccb9c5b8c 2019-08-19 22:43:12 +0000 to 2019-08-27 16:10:51 +0000 - Update and improve zsh completion (rust-lang/cargo#7296) - Document that `package` can be used in `[patch]` (rust-lang/cargo#7263) - Fix `error:`/`warning:` coloring inconsistency with rustc (rust-lang/cargo#7294) - Tests: Import rustc_plugin from its new location (rust-lang/cargo#7287) - Update README azure badge. (rust-lang/cargo#7293) - Update home dependencies to v0.5 (rust-lang/cargo#7277) - Fix typo (rust-lang/cargo#7279) - Update libgit2 dependencies (rust-lang/cargo#7275) - Fix old lockfile encoding wrt newlines (rust-lang/cargo#7262) - Fix dSYM uplifting when symlink is broken (rust-lang/cargo#7268)
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.
We were sporadically but persistently seeing errors like
while running
cargo build. Once the error occurs once,cargo buildwill fail forever with the same error until
target/debug/bin.dSYMismanually unlinked.
After some investigation, I've determined that this situation arises
when the target of
bin.dSYMgoes missing. For example, if bin.dSYM ispointing at
deps/bin-86908f0fa7f1440e.dSYM, anddeps/bin-86908f0fa7f1440e.dSYMdoes not exist, then this error willoccur. I'm still not clear on why the underlying dSYM bundle
sporadically goes missing--perhaps it's the result of pressing Ctrl-C at
the wrong moment?--but Cargo should at least be able to handle this
situation better.
It turns out that Cargo was getting confused by the broken symlink. When
it goes to install the new
target/debug/bin.dSYMlink, it will removethe existing
target/debug/bin.dSYMfile, if it exists. Unfortunately,Cargo was checking whether the target of that symlink existed (e.g.,
deps/bin-86908f0fa7f1440e.dSYM, which in the buggy case would notexist), rather than the symlink itself, deciding that there was no
existing symlink to remove, and crashing with EEXIST when trying to
install the new symlink.
This commit adjusts the existence check to evaluate whether the symlink
itself exists, rather than its target.
Note that while the symptoms are the same as #4671, the root cause is
unrelated.