You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Thanks for the report, definitely seems like a bug! We'll want to handle this by acquiring a read-write lock on the destination we're writing into. If we're extracting a tarball we're already writing files there and we rely on the atomicity of the destination, not the source.
In theory shouldn't be too hard to do internally in Cargo!
Copy crate and keep exclusive lock to it with local registries. Ensures
that only one instance will try to extract the source of a new package.
Fixesrust-lang#6588.
Fix race condition in local registry crate unpacking
Copy crate and keep exclusive lock to it with local registries. Ensures
that only one instance will try to extract the source of a new package.
Fixes#6588.
Problem
There is a race condition when building multiple projects concurrently that depend on the same crates. When extracting crates from a local registry, the crate is opened as read-only with shared locks (https://github.com/rust-lang/cargo/blob/master/src/cargo/sources/registry/local.rs#L74). Unpacking the crate is assumed to be safe due to the tar file being locked (https://github.com/rust-lang/cargo/blob/master/src/cargo/sources/registry/mod.rs#L428).
Output of build failure:
Steps
Possible Solution(s)
$CARGO_HOME
, exclusively locking that copy.$CARGO_HOME
.Notes
Output of
cargo version
:cargo 1.29.0 (524a578d7 2018-08-05)
The text was updated successfully, but these errors were encountered: