diff options
| author | Matthias Krüger <matthias.krueger@famsik.de> | 2024-12-21 22:16:02 +0100 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2024-12-21 22:16:02 +0100 |
| commit | 51df98ddb094b39b2e17d24f887cd66c52560ef6 (patch) | |
| tree | 1a1f3439116ec85e2e28033c5766301979ee1c58 /tests/coverage/branch/lazy-boolean.rs | |
| parent | 4c40c89c26e9a6c761e2c6d44662028e33e9cb04 (diff) | |
| parent | bfadeeb45cf25b996a50e3393967dac460d5cd53 (diff) | |
| download | rust-51df98ddb094b39b2e17d24f887cd66c52560ef6.tar.gz rust-51df98ddb094b39b2e17d24f887cd66c52560ef6.zip | |
Rollup merge of #131072 - Fulgen301:windows-rename-posix-semantics, r=ChrisDenton
Win: Use POSIX rename semantics for `std::fs::rename` if available Windows 10 1601 introduced `FileRenameInfoEx` as well as `FILE_RENAME_FLAG_POSIX_SEMANTICS`, allowing for atomic renaming and renaming if the target file is has already been opened with `FILE_SHARE_DELETE`, in which case the file gets renamed on disk while the open file handle still refers to the old file, just like in POSIX. This resolves #123985, where atomic renaming proved difficult to impossible due to race conditions. If `FileRenameInfoEx` isn't available due to missing support from the underlying filesystem or missing OS support, the renaming is retried with `FileRenameInfo`, which matches the behavior of `MoveFileEx`. This PR also manually replicates parts of `MoveFileEx`'s internal logic, as reverse-engineered from the disassembly: If the source file is a reparse point and said reparse point is a mount point, the mount point itself gets renamed; otherwise the reparse point is resolved and the result renamed. Notes: - Currently, the `win7` target doesn't bother with `FileRenameInfoEx` at all; it's probably desirable to remove that special casing and try `FileRenameInfoEx` anyway if it doesn't exist, in case the binary is run on newer OS versions. Fixes #123985
Diffstat (limited to 'tests/coverage/branch/lazy-boolean.rs')
0 files changed, 0 insertions, 0 deletions
