Fix file path separator decoded from manifest is not correct on Windows

[rhysd]

While installing rust-doc component on Windows, I noticed the following log messages in the output.

info: retrying renaming 'C:\Users\rhysd\.rustup\tmp\d648r0b_lyhd2svq_dir\rust-docs\share/doc/rust/html' to 'C:\Users\rhysd\.rustup\toolchains\stable-x86_64-pc-windows-msvc\share/doc/rust/html'

This log message itself was not a problem, but some path separators were not correct ...\stable-x86_64-pc-windows-msvc\share/doc/rust/html.

After taking a look at sources of rustup, I understood the cause was that the share/doc/rust/html part was decoded from manifest.in directly without converting path separators. This PR fixes it.

[rhysd]

Can I have some review from maintainer? If something is blocking review, I'll happily try to resolve it. So please let me know.

[Rustin170506]

Thanks for your patch. I'll take a look tomorrow.

[Rustin170506]

Does C:\Users\rhysd\.rustup\toolchains\stable-x86_64-pc-windows-msvc\share/doc/rust/html is valid path on Windows? Because I have no Windows PC so I can't test it.

[rhysd]

File path separator on Windows is \. So the path is valid but it does not represent the indented path C:\Users\rhysd\.rustup\toolchains\stable-x86_64-pc-windows-msvc\share\doc\rust\html.

I don't know why it works currently, but I think it would be canonicalized in some layer.

[rbtcollins]

It currently works because the Win32 APIs are flexible. The NT api that underlies it is not, and if we pass in \?\ style paths to the Win32 API it will also not be flexible, from memory. Canonicalising it is the right thing to do. I haven't read the patch at this point, just wanted to say thanks for taking this on and its clearly the right outcome to aim for.

[rhysd]

rustup uses fs::copy recursively so I checked the Windows implementation and understood CopyFileExW is used. But I could not find any document which handles / as \.

https://github.com/rust-lang/rust/blob/1e926f06528ecb2503f026e2fd53cb735d487b10/library/std/src/sys/windows/fs.rs#L1343-L1350

As @rbtcollins kindly shared the thought, I think the current behavior is depending on some implementation details of platform-specific API.

[rbtcollins]

Hi, I've had a look at this. I think the change should be localised to the rename path, rather than the manifest: the change you've made will result in different manifests in the rustup dir depending on OS - that will interact badly with rustup dirs shared on NFS and the like.

I'm not entirely sure that the extra library is worth it - since we're only doing a relatively small number of these operations the overhead of a deconstruct to segments and reconstruct will be quite inivisble.

    42 /home/robertc/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/manifest-cargo-x86_64-unknown-linux-gnu
     5 /home/robertc/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/manifest-clippy-preview-x86_64-unknown-linux-gnu
    26 /home/robertc/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/manifest-rust-analysis-x86_64-unknown-linux-gnu
    25 /home/robertc/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/manifest-rustc-x86_64-unknown-linux-gnu
     1 /home/robertc/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/manifest-rust-docs-x86_64-unknown-linux-gnu
     5 /home/robertc/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/manifest-rustfmt-preview-x86_64-unknown-linux-gnu
  1466 /home/robertc/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/manifest-rust-src
    32 /home/robertc/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/manifest-rust-std-x86_64-unknown-linux-gnu
  1602 total