std: Fix fs::read_link behavior on Windows #24198
Conversation
The current implementation of using GetFinalPathNameByHandle actually reads all intermediate links instead of just looking at the current link. This commit alters the behavior of the function to use a different API which correctly reads only one level of the soft link. [breaking-change]
|
r? @huonw (rust_highfive has picked a reviewer for you, use r? to override) |
|
Could you add a test for this? |
|
@sfackler That would require having a symbolic link to test it on, which requires administrator privileges to create by default. |
|
Ah, bummer. |
|
@sfackler That said, it should be feasible to make the buildbot slaves able to create symbolic links, and have the test attempt to make a symbolic link and read it, and if it fails with insufficient privileges then we can just pass the test anyway. |
I think this is pretty reasonable. Other than that, 👍 to the PR! |
|
Unfortunately I've found that tests that pass when something is disabled to not work out too well in the past. Eventually we'll reconfigure the bots, forget to enable them to create symlinks, and then all the tests will just sit around for a bit not testing much. I will say though that I've manually tested that the implementation works for now at least! |
|
@bors: r+ Thanks for the fix! |
|
📌 Commit f3f99fb has been approved by |
The current implementation of using GetFinalPathNameByHandle actually reads all intermediate links instead of just looking at the current link. This commit alters the behavior of the function to use a different API which correctly reads only one level of the soft link. [breaking-change]
The current implementation of using GetFinalPathNameByHandle actually reads all
intermediate links instead of just looking at the current link. This commit
alters the behavior of the function to use a different API which correctly reads
only one level of the soft link.
[breaking-change]