-
Notifications
You must be signed in to change notification settings - Fork 2.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Re-enable compatibility with readonly CARGO_HOME #6940
Conversation
r? @nrc (rust_highfive has picked a reviewer for you, use r? to override) |
For posterity, the way I tested this was: $ cargo build --features vendored-openssl
$ docker run \
-v `rustc --print sysroot`:/rust:ro \
-e RUSTC=/rust/bin/rustc \
-w /src \
-it \
-v `pwd`:/src \
-v $HOME/.cargo:/cargo:ro \
-e CARGO_HOME=/cargo \
ubuntu:18.04 \
./target/debug/cargo build If that progresses to the point that it fails the build due to a missing I'm not entirely certain if this matches up with Crater's use case, so I'm not 100% certain it will solve it. |
Oh right there's these things called permission bits, let me add a test. |
Previously Cargo would attempt to work as much as possible with a previously filled out CARGO_HOME, even if it was mounted as read-only. In rust-lang#6880 this was regressed as a few global locks and files were always attempted to be opened in writable mode. This commit fixes these issues by correcting two locations: * First the global package cache lock has error handling to allow acquiring the lock in read-only mode inaddition to read/write mode. If the read/write mode failed due to an error that looks like a readonly filesystem then we assume everything in the package cache is readonly and we switch to just acquiring any lock, this time a shared readonly one. We in theory aren't actually doing any synchronization at that point since it's all readonly anyway. * Next when unpacking package we're careful to issue a `stat` call before opening a file in writable mode. This way our preexisting guard to return early if a package is unpacked will succeed before we open anything in writable mode. Closes rust-lang#6928
f09940c
to
5d9383e
Compare
r? @ehuss |
@bors r+ |
📌 Commit 5d9383e has been approved by |
Re-enable compatibility with readonly CARGO_HOME Previously Cargo would attempt to work as much as possible with a previously filled out CARGO_HOME, even if it was mounted as read-only. In #6880 this was regressed as a few global locks and files were always attempted to be opened in writable mode. This commit fixes these issues by correcting two locations: * First the global package cache lock has error handling to allow acquiring the lock in read-only mode inaddition to read/write mode. If the read/write mode failed due to an error that looks like a readonly filesystem then we assume everything in the package cache is readonly and we switch to just acquiring any lock, this time a shared readonly one. We in theory aren't actually doing any synchronization at that point since it's all readonly anyway. * Next when unpacking package we're careful to issue a `stat` call before opening a file in writable mode. This way our preexisting guard to return early if a package is unpacked will succeed before we open anything in writable mode. Closes #6928
☀️ Test successful - checks-travis, status-appveyor |
Update cargo 17 commits in 759b6161a328db1d4863139e90875308ecd25a75..c4fcfb725b4be00c72eb9cf30c7d8b095577c280 2019-05-06 20:47:49 +0000 to 2019-05-15 19:48:47 +0000 - tests: registry: revert readonly permission after running tests. (rust-lang/cargo#6947) - Remove Candidate (rust-lang/cargo#6946) - Fix for "Running cargo update without a Cargo.lock ignores arguments" rust-lang/cargo#6872 (rust-lang/cargo#6904) - Fix a minor mistake in the changelog. (rust-lang/cargo#6944) - Give a better error message when crates.io requests time out (rust-lang/cargo#6936) - Re-enable compatibility with readonly CARGO_HOME (rust-lang/cargo#6940) - Fix version of `ignore`. (rust-lang/cargo#6938) - Stabilize offline mode. (rust-lang/cargo#6934) - zsh: Add doc options to include non-public items documentation (rust-lang/cargo#6929) - zsh: Suggest --lib option as binary template now the default (rust-lang/cargo#6926) - Migrate package include/exclude to gitignore patterns. (rust-lang/cargo#6924) - Implement the Cargo half of pipelined compilation (take 2) (rust-lang/cargo#6883) - Always include `Cargo.toml` when packaging. (rust-lang/cargo#6925) - Remove unnecessary calls to masquerade_as_nightly_cargo. (rust-lang/cargo#6923) - download: fix "Downloaded 1 crates" message (crates -> crate) (rust-lang/cargo#6920) - Changed RUST_LOG usage to CARGO_LOG to avoid confusion. (rust-lang/cargo#6918) - crate download: don't print that a crate was the largest download if it was the only download (rust-lang/cargo#6916)
Is this PR a full solution to the issue given NixOS/nixpkgs#61618? |
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
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
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
Does this mean the cache should work in read-only mode too? We've got rust builds running in CI/CD, we'd like the rust toolchain directory and cargo binaries (eg cargo, fmt, etc) to be read-only for the service account running the builds, but at the moment that gets messed up because the cache directory is the same as CARGO_HOME. |
Previously Cargo would attempt to work as much as possible with a
previously filled out CARGO_HOME, even if it was mounted as read-only.
In #6880 this was regressed as a few global locks and files were always
attempted to be opened in writable mode.
This commit fixes these issues by correcting two locations:
First the global package cache lock has error handling to allow
acquiring the lock in read-only mode inaddition to read/write mode. If
the read/write mode failed due to an error that looks like a readonly
filesystem then we assume everything in the package cache is readonly
and we switch to just acquiring any lock, this time a shared readonly
one. We in theory aren't actually doing any synchronization at that
point since it's all readonly anyway.
Next when unpacking package we're careful to issue a
stat
callbefore opening a file in writable mode. This way our preexisting guard
to return early if a package is unpacked will succeed before we open
anything in writable mode.
Closes #6928