Skip to content

Implement file cloning on Windows #4344

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
May 28, 2025

Conversation

CraftSpider
Copy link
Contributor

Just requires expanding what we can do with handles - get the current process pseudo-handle, and the Windows version of dup.


if this.ptr_is_null(target_handle_ptr)? {
throw_unsup_format!(
"`DuplicateHandle` `lpTargetHandle` parameter is null, which is unsupported"
Copy link
Contributor

Choose a reason for hiding this comment

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

The official docs say

If lpTargetHandle is NULL, the function duplicates the handle, but does not return the duplicate handle value to the caller. This behavior exists only for backward compatibility with previous versions of this function. You should not use this feature, as you will lose system resources until the target process terminates.

So unsupported is correct, but that doesn't have to be in the error message. The message could just say that the pointer must not be null because the handle must be written somewhere or it would get leaked

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I wasn't sure if we wanted to consider this case 'unsupported by Miri' or 'viewed as a bug by Miri'. I'm fine with considering it to be a program bug.

Copy link
Contributor

Choose a reason for hiding this comment

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

yea it's a weird balance. "unsupported" hints at "may add support", which considering the official docs I would say we won't do

"`DuplicateHandle` called on a thread handle, which is unsupported"
);
}
Handle::Pseudo(pseudo) => Handle::Pseudo(pseudo),
Copy link
Contributor

Choose a reason for hiding this comment

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

Do we have tests for this code path?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

No, we don't currently directly test any of the handle shims outside of ones used directly for filesystem stuff. I can add such tests when I get a chance.

Copy link
Contributor

Choose a reason for hiding this comment

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

yea may be good to test these code paths, but also preexisting, so nothing urgent

@oli-obk oli-obk added this pull request to the merge queue May 28, 2025
Merged via the queue into rust-lang:master with commit 0f6f9d6 May 28, 2025
8 checks passed
@RalfJung
Copy link
Member

RalfJung commented May 28, 2025

As a follow-up, could you add a test directly calling the shim (tests/pass-dep/shims/windows-fs.rs seems like a good place)?

I'm trying to ensure as many shims as possible have at least smoke tests invoking them directly and not via std so that we are more robust against std implementation changes. :)
(See #3179)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants