-
Notifications
You must be signed in to change notification settings - Fork 13.3k
Win: Fix std::fs::rename failing on Windows Server by attempting the non-atomic rename first #138133
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
base: master
Are you sure you want to change the base?
Conversation
…non-atomic rename first We previously attempted the atomic rename first, and fell back to trying a non-atomic rename if it wasn't supported. However, this does not work reliably on Windows Server - NTFS partitions created in Windows Server 2016 apparently need to be upgraded, and it outright fails with `ERROR_NOT_SUPPORTED` on ReFS on Windows Server 2022. This commit switches the two calls so that FileRenameInfo is tried first, and an atomic rename via FileRenameInfoEx is only attempted if the non-atomic rename fails.
r? @ChrisDenton rustbot has assigned @ChrisDenton. Use |
☔ The latest upstream changes (presumably #138208) made this pull request unmergeable. Please resolve the merge conflicts. |
Ok, I've been testing this on many Windows versions and on different filesystem. I think the better approach is to test for the following error codes:
|
What are the non-atomic semantics on windows? Unix software generally expects renames to be atomic. |
@rustbot author |
Reminder, once the PR becomes ready for a review, use |
We previously attempted the atomic rename first, and fell back to trying a non-atomic rename if it wasn't supported. However, this does not work reliably on Windows Server - NTFS partitions created in Windows Server 2016 apparently need to be upgraded, and it outright fails with
ERROR_NOT_SUPPORTED
on ReFS on Windows Server 2022.This commit switches the two calls so that FileRenameInfo is tried first, and an atomic rename via FileRenameInfoEx is only attempted if the non-atomic rename fails.
Fix #137499.
Fix #137971.
This PR works similarly to #137528, but is a cleaner fix in my opinion and avoids additional syscalls to reopen the file if
MoveFileEx
fails.