Spurious PermissionDenied error with cargo's `rename_with_link_search_path` test in AppVeyor

[kennytm]

Symptom: The check-aux job fails with the following log:

failures:
---- rename_with_link_search_path stdout ----
	running `C:\projects\rust\build\x86_64-pc-windows-msvc\stage2-tools\x86_64-pc-windows-msvc\release\cargo.exe build`
running `C:\projects\rust\build\x86_64-pc-windows-msvc\stage2-tools\x86_64-pc-windows-msvc\release\cargo.exe run`
thread 'rename_with_link_search_path' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 5, kind: PermissionDenied, message: "Access is denied." }', libcore\result.rs:945:5
note: Run with `RUST_BACKTRACE=1` for a backtrace.
failures:
    rename_with_link_search_path
test result: FAILED. 63 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out

First seen in #48476 (comment), and again in #47463 (comment).

[alexcrichton]

I've made an attempt to mitigate this at rust-lang/cargo#5131

[alexcrichton]

I'm pretty certain the failing call to unwrap is here and AFIAK this is the same error that we've been battling with since the beginning of time in MSVC. On Windows you can't rename/delete files that are currently open, which is typically fine unless something unkknowingly opens one of your files.

I think (basically never confirmed) that on MSVC the link.exe linker will spawn off mspdbsrv.exe to finish in the background after link.exe exits. I believe this means that when cargo.exe exits, various files in the output directory may still be open for writing, for example by mspdbsrv.exe. This in turn prevents Cargo in tests from doing a build then deleting the folder right after.

What's happening here is that this test is specifically testing that if the build directory is renamed then it doesn't try to use the old contents, so it requires the old build directory to get blown away. Now that fails spuriously on MSVC and I have no idea how to fix it...

I'd love to figure out a way to either disable this mspdbsrv.exe background behavior or figure out a way to synchronize with it. In the meantime though the only way I'd know how to solve this is to disable the test on MSVC, which while possible is of course not great...

[Mark-Simulacrum]

This looks like it may have some potential: http://blog.peter-b.co.uk/2017/02/stop-mspdbsrv-from-breaking-ci-build.html -- we may be able to spawn our own mspdbsrv and then that way avoid it having any file handles open that we don't want it to have open.

[alexcrichton]

Nice find! I think we could definitely try that but I'm not sure if it'd solve our problem. I was gonna write out steps with an example but apparently nothing I do locally seems to convince mspdbsrv.exe to get spawned... I'm not sure!

Historically though I think the problem has been that mspdbsrv.exe doesn't itself hold anything open but rather is writing out a file as we're trying to delete it. AFAIK the link.exe exit isn't synchronized with the output of mspdbsrv.exe, so you might have files emitted after the linker exits (like debuginfo). This means that if try to delete the directory at the same time it can cause problems.

I'm... not sure why I can't reproduce this locally. I wonder if newer versions of visual studio have removed mspdbsrv.exe? Maybe I'm not using the right flags? hmm...

[alexcrichton]

I've attempted to mitigate this in rust-lang/cargo#5488