Skip to content

Move the Windows remove_dir_all impl into a module and make it more race resistant #129800

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

Merged
merged 1 commit into from
Sep 3, 2024

Conversation

ChrisDenton
Copy link
Member

@ChrisDenton ChrisDenton commented Aug 31, 2024

This attempts to make the Windows implementation of remove_dir_all easier to understand and work with by separating out different concerns into their own functions. The code is mostly the same as before just moved around. There are some changes to make it more robust against races (e.g. two calls to remove_dir_all running concurrently). The module level comment explains the issue.

try-job: x86_64-msvc
try-job: i686-msvc

@rustbot rustbot added O-windows Operating system: Windows S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Aug 31, 2024
@rust-log-analyzer

This comment has been minimized.

@rustbot rustbot added the A-run-make Area: port run-make Makefiles to rmake.rs label Sep 1, 2024
@rustbot
Copy link
Collaborator

rustbot commented Sep 1, 2024

This PR modifies tests/run-make/. If this PR is trying to port a Makefile
run-make test to use rmake.rs, please update the
run-make port tracking issue
so we can track our progress. You can either modify the tracking issue
directly, or you can comment on the tracking issue and link this PR.

cc @jieyouxu

@ChrisDenton
Copy link
Member Author

I've enabled the test so I'll make extra sure it works in CI.

@bors try

bors added a commit to rust-lang-ci/rust that referenced this pull request Sep 1, 2024
Move the Windows remove_dir_all impl into a module and make it more race resistant

This attempts to make the Windows implementation of `remove_dir_all` easier to understand and work with by separating out different concerns into their own functions. The code is mostly the same as before just moved around. There are some changes to make it more robust against races (e.g. two calls to `remove_dir_all` running concurrently). The module level comment explains the issue.

try-job: x86_64-msvc
try-job: i686-msvc
@bors
Copy link
Collaborator

bors commented Sep 1, 2024

⌛ Trying commit fca4020 with merge 0de7b4a...

@rust-log-analyzer

This comment has been minimized.

@bors
Copy link
Collaborator

bors commented Sep 2, 2024

💔 Test failed - checks-actions

@bors bors added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Sep 2, 2024
@ChrisDenton
Copy link
Member Author

@bors try

@bors
Copy link
Collaborator

bors commented Sep 2, 2024

⌛ Trying commit 3b6f0ec with merge f823093...

bors added a commit to rust-lang-ci/rust that referenced this pull request Sep 2, 2024
Move the Windows remove_dir_all impl into a module and make it more race resistant

This attempts to make the Windows implementation of `remove_dir_all` easier to understand and work with by separating out different concerns into their own functions. The code is mostly the same as before just moved around. There are some changes to make it more robust against races (e.g. two calls to `remove_dir_all` running concurrently). The module level comment explains the issue.
@bors
Copy link
Collaborator

bors commented Sep 2, 2024

☀️ Try build successful - checks-actions
Build commit: f823093 (f823093a836e2e652e64835d792119f822f74de3)

@ChrisDenton
Copy link
Member Author

oops, I was trying linux. Let's do that again...

@bors try

bors added a commit to rust-lang-ci/rust that referenced this pull request Sep 2, 2024
Move the Windows remove_dir_all impl into a module and make it more race resistant

This attempts to make the Windows implementation of `remove_dir_all` easier to understand and work with by separating out different concerns into their own functions. The code is mostly the same as before just moved around. There are some changes to make it more robust against races (e.g. two calls to `remove_dir_all` running concurrently). The module level comment explains the issue.

try-job: x86_64-msvc
try-job: i686-msvc
@bors
Copy link
Collaborator

bors commented Sep 2, 2024

⌛ Trying commit 3b6f0ec with merge ece733c...

@rust-log-analyzer

This comment has been minimized.

@bors
Copy link
Collaborator

bors commented Sep 2, 2024

💔 Test failed - checks-actions

@ChrisDenton
Copy link
Member Author

Ok, I'm going to give up on enabling the test for now. Given existing CI issues, I fear it's going to be a bit flaky no matter what.

fn delete(parent: &File, name: &[u16]) -> Result<(), WinError> {
// Note that the `delete` function consumes the opened file to ensure it's
// dropped immediately. See module comments for why this is important.
match open_link_no_reparse(parent, name, c::SYNCHRONIZE | c::DELETE) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can't we just use NtDeleteFile here and avoid having to temporarily open the file? Would this avoid the ERROR_DELETE_PENDING case?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

NtDeleteFile has a couple of issues:

  • the file isn't deleted until every handle to it is closed, system wide
  • it doesn't delete files that have the readonly attribute set (which, for example, git makes heavy use of)

@Amanieu
Copy link
Member

Amanieu commented Sep 2, 2024

@bors r+

@bors
Copy link
Collaborator

bors commented Sep 2, 2024

📌 Commit bb9d5c4 has been approved by Amanieu

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Sep 2, 2024
bors added a commit to rust-lang-ci/rust that referenced this pull request Sep 3, 2024
…iaskrgr

Rollup of 8 pull requests

Successful merges:

 - rust-lang#129152 (custom/external clippy support for bootstrapping)
 - rust-lang#129311 (don't copy `.rustc-dev-contents` from CI rustc)
 - rust-lang#129800 (Move the Windows remove_dir_all impl into a module and make it more race resistant)
 - rust-lang#129860 (update `object` dependency to remove duplicate `wasmparser`)
 - rust-lang#129885 (chore: remove repetitive words)
 - rust-lang#129913 (Add missing read_buf stub for x86_64-unknown-l4re-uclibc)
 - rust-lang#129916 (process.rs: remove "Basic usage" text where not useful)
 - rust-lang#129917 (Fix parsing of beta version in dry-run mode)

r? `@ghost`
`@rustbot` modify labels: rollup
@bors bors merged commit 72cc383 into rust-lang:master Sep 3, 2024
12 checks passed
@rustbot rustbot added this to the 1.83.0 milestone Sep 3, 2024
rust-timer added a commit to rust-lang-ci/rust that referenced this pull request Sep 3, 2024
Rollup merge of rust-lang#129800 - ChrisDenton:remove-dir-all2, r=Amanieu

Move the Windows remove_dir_all impl into a module and make it more race resistant

This attempts to make the Windows implementation of `remove_dir_all` easier to understand and work with by separating out different concerns into their own functions. The code is mostly the same as before just moved around. There are some changes to make it more robust against races (e.g. two calls to `remove_dir_all` running concurrently). The module level comment explains the issue.

try-job: x86_64-msvc
try-job: i686-msvc
workingjubilee added a commit to workingjubilee/rustc that referenced this pull request Sep 18, 2024
…nieu

Win: Open dir for sync access in remove_dir_all

A small follow up to rust-lang#129800.

We should explicitly open directories for synchronous access. We ultimately use `GetFileInformationByHandleEx` to read directories which should paper over any issues caused by using async directory reads (or else return an error) but it's better to do the right thing in the first place. Note though that `delete` does not read or write any data so it's not necessary there.
workingjubilee added a commit to workingjubilee/rustc that referenced this pull request Sep 18, 2024
…nieu

Win: Open dir for sync access in remove_dir_all

A small follow up to rust-lang#129800.

We should explicitly open directories for synchronous access. We ultimately use `GetFileInformationByHandleEx` to read directories which should paper over any issues caused by using async directory reads (or else return an error) but it's better to do the right thing in the first place. Note though that `delete` does not read or write any data so it's not necessary there.
rust-timer added a commit to rust-lang-ci/rust that referenced this pull request Sep 19, 2024
Rollup merge of rust-lang#129934 - ChrisDenton:remove-dir-all3, r=Amanieu

Win: Open dir for sync access in remove_dir_all

A small follow up to rust-lang#129800.

We should explicitly open directories for synchronous access. We ultimately use `GetFileInformationByHandleEx` to read directories which should paper over any issues caused by using async directory reads (or else return an error) but it's better to do the right thing in the first place. Note though that `delete` does not read or write any data so it's not necessary there.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-run-make Area: port run-make Makefiles to rmake.rs O-windows Operating system: Windows S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-libs Relevant to the library team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants