cargo vendor outputs directory with \\?\ on Windows if it previously existed

[Vlad-Shcherbina]

To reproduce

1. cargo new cargo_vendor_is_broken
2. cd cargo_vendor_is_broken
3. cargo vendor
4. cargo vendor

Expected result
Steps 3 and 4 should produce the same output.

Actual result

>cargo vendor
To use vendored sources, add this to your .cargo/config for this project:

[source.vendored-sources]
directory = "vendor"

>cargo vendor
To use vendored sources, add this to your .cargo/config for this project:

[source.vendored-sources]
directory = "\\\\?\\C:\\temp\\rust_playground\\cargo_vendor_is_broken\\vendor"

Version info

Windows

>cargo version
cargo 1.39.0-nightly (3f700ec43 2019-08-19)

[alexcrichton]

Is there a particular reason why you consider this to be broken? It's true that it's odd that there's two values here, but I think they both work?

[Vlad-Shcherbina]

"Broken" may be a wrong word choice on my part. As far as I know, this issue does not affect me directly. I reported it because it looks like a symptom of some underlying problem. If the command does a different thing merely because it's being run a second time, what will it do on the Full Moon?

Besides, if these paths are indeed equivalent, there is no apparent reason to output "\\\\?\\C:\\temp\\rust_playground\\cargo_vendor_is_broken\\vendor" where "vendor" suffices.

[agashlin]

Coming from the other issue, a problem is that cargo-vendor would always use the "normal" path style ("C:\\temp\\rust_playground\\cargo_vendor_is_broken\\vendor"), so it's not a drop-in replacement without some work (Python's os.path doesn't like mixing \\?\ with the other kind, ref mach vendor rust fails on Windows).

This issue came up previously in cargo-vendor, I don't know if there were discussions around that decision since.

[ehuss]

This seems to be fixed by #7629.