Don't fail if we can't acquire readonly lock #7149
Conversation
This commit updates support from rust-lang#6940 to not only gracefully handle situations where the lock can be acquired in readonly but not read/write mode but also handle situations where even a readonly lock can't be acquired. If a readonly lock can't be acquired (and the read/write failed) then we likely can't touch anything in the directory, so there's no value gained from locking anyway. Closes rust-lang#7147
|
r? @nrc (rust_highfive has picked a reviewer for you, use r? to override) |
rust-highfive
added
the
S-waiting-on-review
|
@bors r+ |
|
📌 Commit 650ae65 has been approved by |
bors
added
S-waiting-on-bors
Don't fail if we can't acquire readonly lock This commit updates support from #6940 to not only gracefully handle situations where the lock can be acquired in readonly but not read/write mode but also handle situations where even a readonly lock can't be acquired. If a readonly lock can't be acquired (and the read/write failed) then we likely can't touch anything in the directory, so there's no value gained from locking anyway. Closes #7147
|
☀️ Test successful - checks-travis, status-appveyor |
|
I can still reproduce this issue on stable, beta and nightly when the -- edit: Adding references of other github issue: |
|
@nbp nightly hasn't been updated, yet. It is updated around once a week, I'll probably do it today, and it may show up in a couple days after that. |
|
Thanks for the notice, I did not saw that this was only fixed 4 days ago. Would it be possible to backport it to stable once it is checked on Nightly? |
|
It may be difficult to backport to stable. Generally stable point releases are only made for very critical issues, and AFAIK there isn't anything queued to justify a stable release. I realize that breaking the build for Debian is painful, though. I think that's a call for the release team. I'm not sure what the official process would be, but I would just ask them on I'll prepare a beta backport now, though. |
Update cargo 11 commits in e3563dbdcd2e370bc4f11d080f739d82d25773fd..d0f828419d6ce6be21a90866964f58eb2c07cd56 2019-07-16 19:22:44 +0000 to 2019-07-23 21:58:59 +0000 - Remove include/exclude glob warning. (rust-lang/cargo#7170) - Optimize lock file format for git merge conflicts (rust-lang/cargo#7070) - Set up CI with Azure Pipelines (rust-lang/cargo#7139) - Force clippy to run. (rust-lang/cargo#7157) - Work around #61440 (rust-lang/cargo#7158) - initial working version of cargo fix --clippy (rust-lang/cargo#7069) - Optimize runtime of `#[cargo_test_macro]` (rust-lang/cargo#7146) - Don't fail if we can't acquire readonly lock (rust-lang/cargo#7149) - Add support for multiple --features options (rust-lang/cargo#7084) - Fix a typo in an env var name (rust-lang/cargo#7145) - Add a way to disable all nightly tests (rust-lang/cargo#7142)
This commit updates support from #6940 to not only gracefully handle
situations where the lock can be acquired in readonly but not read/write
mode but also handle situations where even a readonly lock can't be
acquired. If a readonly lock can't be acquired (and the read/write
failed) then we likely can't touch anything in the directory, so there's
no value gained from locking anyway.
Closes #7147