-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
test-infra: improve compiletest and run-make-support symlink handling #134659
base: master
Are you sure you want to change the base?
Conversation
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
ec25265
to
ad3b2ad
Compare
This comment has been minimized.
This comment has been minimized.
Can I ask why you need to FORCE PERMISSIONS? |
ad3b2ad
to
77d24da
Compare
... good question. For some reason I completely forgot about this. Let me revert it real quick. EDIT: ah, but I will need to force perms when the root path is a non-dir entry. Does |
77d24da
to
61a697d
Compare
It should do. I'd be minded to try something like: #[cfg(windows)]
use std::os::windows::fs::FileTypeExt;
pub fn recursive_remove<P: AsRef<Path>>(path: P) -> io::Result<()> {
let path = path.as_ref();
let metadata = fs::symlink_metadata(path)?;
#[cfg(windows)]
let is_dir = |meta: &fs::Metadata| meta.is_dir() || meta.file_type().is_symlink_dir();
#[cfg(not(windows))]
let is_dir = fs::Metadata::is_dir;
if is_dir(&metadata) { fs::remove_dir_all(path) } else { fs::remove_file(path) }
} |
920e230
to
bba8509
Compare
Thanks, that indeed is what I needed to do, just needed to additionally handle the special case of root path being a non-dir read-only entry. |
This comment has been minimized.
This comment has been minimized.
bba8509
to
5bb55fe
Compare
Chris said I can |
…omponent, r=<try> Migrate `incr-add-rust-src-component` to rmake **BLOCKED: this PR depends on rust-lang#134659** **TODO: actually write some useful PR description** r? `@ghost` try-job: i686-msvc try-job: x86_64-mingw-1 try-job: x86_64-msvc try-job: aarch64-apple
std should probably make |
@bors rollup=iffy (who knows what this will fail on) |
Ok, this version looks good to me. And I do like having a range of tests. @bors r+ |
This comment has been minimized.
This comment has been minimized.
@bors r- I was so focused on Windows I missed the Linux, ha |
fbc60e6
to
a001eff
Compare
I just added a |
…omponent, r=<try> Migrate `incr-add-rust-src-component` to rmake **BLOCKED: this PR depends on rust-lang#134659** **TODO: actually write some useful PR description** r? `@ghost` try-job: i686-msvc try-job: x86_64-mingw-1 try-job: x86_64-msvc try-job: aarch64-apple
Hm, yeah, I'd prefer |
`recursive_remove` is intended to be a wrapper around `std::fs::remove_dir_all`, but which also allows the removal target to be a non-directory entry, i.e. a file or a symlink. It also tries to remove read-only attributes from filesystem entities on Windows for non-dir entries, as `std::fs::remove_dir_all` handles the dir (and its children) read-only cases. Co-authored-by: Chris Denton <[email protected]>
`aggressive_rm_rf` does not correctly handle distinction between symlink-to-file vs symlink-to-dir on Windows.
This facade is like other `run_make_support::fs` APIs that panic-on-failure but includes the path that the operation was called on in the panic message.
a001eff
to
4d3bf1f
Compare
Changed to use |
@rustbot ready |
@bors r+ |
…Denton test-infra: improve compiletest and run-make-support symlink handling I was trying to implement rust-lang#134656 to port `tests/run-make/incr-add-rust-src-component.rs`, but found some blockers related to symlink handling, so in this PR I tried to resolve them by improving symlink handling in compiletest and run-make-support (particularly for native windows msvc environment). Key changes: - I needed to copy symlinks (duplicate a symlink pointing to the same file), so I pulled out the copy symlink logic and re-exposed it as `run_make_support::rfs::copy_symlink`. This helper correctly accounts for the Windows symlink-to-file vs symlink-to-dir distinction (hereafter "Windows symlinks") when copying symlinks. - `recursive_remove`: - I needed a way to remove symlinks themselves (no symlink traversal). `std::fs::remove_dir_all` handles them, but only if the root path is a directory. So I wrapped `std::fs::remove_dir_all` to also handle when the root path is a non-directory entity (e.g. file or symlink). Again, this properly accounts for Windows symlinks. - I wanted to use this for both compiletest and run-make-support, so I put the implementation and accompanying tests in `build_helper`. - In this sense, it's a reland of rust-lang#129302 with proper test coverage. - It's a thin wrapper around `std::fs::remove_dir_all` (`remove_dir_all` correctly handles read-only entries on Windows). The helper has additional permission-setting logic for when the root path is a non-dir entry on Windows to handle read-only non-dir entry. Fixes rust-lang#126334.
I was trying to implement #134656 to port
tests/run-make/incr-add-rust-src-component.rs
, but found some blockers related to symlink handling, so in this PR I tried to resolve them by improving symlink handling in compiletest and run-make-support (particularly for native windows msvc environment).Key changes:
run_make_support::rfs::copy_symlink
. This helper correctly accounts for the Windows symlink-to-file vs symlink-to-dir distinction (hereafter "Windows symlinks") when copying symlinks.recursive_remove
:std::fs::remove_dir_all
handles them, but only if the root path is a directory. So I wrappedstd::fs::remove_dir_all
to also handle when the root path is a non-directory entity (e.g. file or symlink). Again, this properly accounts for Windows symlinks.build_helper
.std::fs::remove_dir_all
now that it is available #129302 with proper test coverage.std::fs::remove_dir_all
(remove_dir_all
correctly handles read-only entries on Windows). The helper has additional permission-setting logic for when the root path is a non-dir entry on Windows to handle read-only non-dir entry.Fixes #126334.