-
Notifications
You must be signed in to change notification settings - Fork 13.1k
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
Windows: remove readonly files #134679
Windows: remove readonly files #134679
Conversation
rustbot has assigned @Mark-Simulacrum. Use |
Could you add that to the platform-specific behavior section of |
I've added a note about which functions are used. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we need libs/libs-api FCP of some kind given the new (at least implicit) guarantee? The impl seems fine but I don't have the Windows knowledge to thoroughly check it.
let mut opts = OpenOptions::new(); | ||
opts.access_mode(c::DELETE); | ||
opts.custom_flags(c::FILE_FLAG_OPEN_REPARSE_POINT); | ||
if File::open_native(&p_u16s, &opts).map(|f| f.posix_delete()).is_ok() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could this cause concurrent deletes of the same file to fail due to having an open handle (iirc windows doesn't let you delete files with open handles?)? I guess before it would also fail with the same error, so not sure that matters even if true...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
DeleteFile
does also open the file in a similar way to we're doing so there's actually no change there.
iirc windows doesn't let you delete files with open handles
That's not quite right. When opening files there's a "sharing mode" that lets you allow others to open the same file. One of those modes is FILE_SHARE_DELETE
. If someone opens a file without that share mode then it will prevent any deletions no matter what we do.
Deletes can also race with each other because there's a time between marking a file for deletion and closing the handle where the file is in a kind of limbo state. It can't be opened but it still exists on the filesystem.
But either case is the same whether we use DeleteFile
or open the file ourselves.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see, sounds good. Thanks for clarifying! :)
I'll add a label to see if libs-api want to discuss it. This aligns the behaviour with other platforms so I think it's worthwhile. |
Oh, I should write a summary of the question being asked of libs-api @rust-lang/libs-api on platforms except Windows, read-only files are deleted when calling This PR changes Does this new (for Windows) behaviour require a libs-api FCP? |
@rustbot ping windows |
Hey Windows Group! This bug has been identified as a good "Windows candidate". cc @albertlarsan68 @arlosi @ChrisDenton @danielframpton @gdr-at-ms @kennykerr @luqmana @lzybkr @nico-abram @retep998 @sivadeilra @wesleywiser |
@rfcbot fcp merge |
Team member @dtolnay has proposed to merge this. The next step is review by the rest of the tagged team members: No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See this document for info about what commands tagged team members can give me. |
🔔 This is now entering its final comment period, as per the review above. 🔔 |
The final comment period, with a disposition to merge, as per the review above, is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. This will be merged soon. |
The libs-api team discussed this, the RFC is now complete and Mark said the implementation looked fine so... @bors r=Mark-Simulacrum |
@bors try |
Windows: remove readonly files When calling `remove_file`, we shouldn't fail to delete readonly files. As the test makes clear, this make the Windows behaviour consistent with other platforms. This also makes us internally consistent with `remove_dir_all`. try-job: x86_64-msvc-ext1
This comment has been minimized.
This comment has been minimized.
💔 Test failed - checks-actions |
That looks like a genuine failure, I'll fix. |
6ffc9ca
to
962ebf0
Compare
I added a rust integration test that asserts deleting a running binary fails on Windows. I made it an integration test because one "failure" mode would be to somehow actually delete the running binary and I wasn't sure that would be a good idea for unit tests. An alternative would be a full blown run-make test that compiles a separate executable to run and delete but that seemed like overkill for this. @rustbot ready |
@bors r+ |
…mulacrum Windows: remove readonly files When calling `remove_file`, we shouldn't fail to delete readonly files. As the test makes clear, this make the Windows behaviour consistent with other platforms. This also makes us internally consistent with `remove_dir_all`. try-job: x86_64-msvc-ext1
Rollup of 5 pull requests Successful merges: - rust-lang#134679 (Windows: remove readonly files) - rust-lang#136213 (Allow Rust to use a number of libc filesystem calls) - rust-lang#136530 (Implement `x perf` directly in bootstrap) - rust-lang#136601 (Detect (non-raw) borrows of null ZST pointers in CheckNull) - rust-lang#136659 (Pick the max DWARF version when LTO'ing modules with different versions ) r? `@ghost` `@rustbot` modify labels: rollup
Rollup of 5 pull requests Successful merges: - rust-lang#134679 (Windows: remove readonly files) - rust-lang#136213 (Allow Rust to use a number of libc filesystem calls) - rust-lang#136530 (Implement `x perf` directly in bootstrap) - rust-lang#136601 (Detect (non-raw) borrows of null ZST pointers in CheckNull) - rust-lang#136659 (Pick the max DWARF version when LTO'ing modules with different versions ) r? `@ghost` `@rustbot` modify labels: rollup
Rollup of 5 pull requests Successful merges: - rust-lang#134679 (Windows: remove readonly files) - rust-lang#136213 (Allow Rust to use a number of libc filesystem calls) - rust-lang#136530 (Implement `x perf` directly in bootstrap) - rust-lang#136601 (Detect (non-raw) borrows of null ZST pointers in CheckNull) - rust-lang#136659 (Pick the max DWARF version when LTO'ing modules with different versions ) r? `@ghost` `@rustbot` modify labels: rollup
Rollup merge of rust-lang#134679 - ChrisDenton:rm-readonly, r=Mark-Simulacrum Windows: remove readonly files When calling `remove_file`, we shouldn't fail to delete readonly files. As the test makes clear, this make the Windows behaviour consistent with other platforms. This also makes us internally consistent with `remove_dir_all`. try-job: x86_64-msvc-ext1
…oratrieb ignore win_delete_self test in Miri Follow-up to rust-lang#134679, fixes miri-test-libstd on Windows Cc `@ChrisDenton` `@Mark-Simulacrum`
Rollup merge of rust-lang#136805 - RalfJung:miri-win-delete-self, r=Noratrieb ignore win_delete_self test in Miri Follow-up to rust-lang#134679, fixes miri-test-libstd on Windows Cc `@ChrisDenton` `@Mark-Simulacrum`
When calling
remove_file
, we shouldn't fail to delete readonly files. As the test makes clear, this make the Windows behaviour consistent with other platforms. This also makes us internally consistent withremove_dir_all
.try-job: x86_64-msvc-ext1