build_script_build.exe in a Windows Sandbox shared folder is filled with zero bytes

[voltagex]

Testing this on Windows 10.0.19045.2846, Windows Sandbox and Hyper-V enabled.

• First, create a .wsb file with the following contents:

<Configuration>
  <MappedFolders>
    <MappedFolder> 
      <HostFolder>C:\test</HostFolder> 
      <SandboxFolder>C:\test</SandboxFolder> 
    </MappedFolder>
  </MappedFolders>
</Configuration>

• Create c:\test on your host PC.
• Double click the wsb file to launch the sandbox.
• Confirm you have c:\test inside the sandbox.

The next steps should be done inside the sandbox.

• Install Rust via rustup-init.exe. This will also pull down a "minimal" Visual Studio (sidenote: you can add a flag to your VS setup invocation to make it run without user input, but still show what it's doing)

• Close the Visual Studio windows that are launched (?) so that rustup-init continues.

• Then try creating a new application and add proc-macro2 to its dependencies (this does not just impact this package, it'll be anything that uses build_script_build.exe IMO). Note that I am using the shared folder here.

PS C:\Users\WDAGUtilityAccount> cd c:\test
PS C:\test> cargo new build-test
     Created binary (application) `build-test` package
PS C:\test> cd .\build-test\
PS C:\test\build-test> cargo add proc-macro2
    Updating crates.io index
      Adding proc-macro2 v1.0.56 to dependencies.
             Features:
             + proc-macro
             - nightly
             - span-locations
    Updating crates.io index
PS C:\test\build-test> cargo build
  Downloaded proc-macro2 v1.0.56
  Downloaded unicode-ident v1.0.8
  Downloaded 2 crates (86.4 KB) in 0.78s
   Compiling proc-macro2 v1.0.56
   Compiling unicode-ident v1.0.8
error: failed to run custom build command for `proc-macro2 v1.0.56`
Caused by:
  could not execute process `C:\test\build-test\target\debug\build\proc-macro2-367b58302398b1c3\build-script-build` (never executed)

Caused by:
  The file or directory is corrupted and unreadable. (os error 1392)

If I create a new directory that IS NOT shared and create a new application

PS C:\test2> cargo add proc-macro2; cargo build
    Updating crates.io index
      Adding proc-macro2 v1.0.56 to dependencies.
             Features:
             + proc-macro
             - nightly
             - span-locations
    Updating crates.io index
   Compiling proc-macro2 v1.0.56
   Compiling unicode-ident v1.0.8
   Compiling test2 v0.1.0 (C:\test2)
    Finished dev [unoptimized + debuginfo] target(s) in 1.57s

Now, the most interesting part of this:

.exe files created in the shared folder, e.g. C:\test\build-test\target\debug\build\proc-macro2-367b58302398b1c3 are zeroed. the .d file and the .pdb seem to be fine though!

build-test.zip cargo-build-msvc-link.zip - procmon trace, stable

I first noticed this on stable, reproduced here with

rustc 1.71.0-nightly (5cdb7886a 2023-04-15)
cargo 1.71.0-nightly (84b7041fd 2023-04-13)

I believe this to be an issue with the way Windows Sandbox shared folders work but it needs someone with more experience in both Windows and Rust to have a look.

This may need to be re-tested on Windows 11 as well.

[Edit: I can't reproduce this with the GNU toolchain!]

[ChrisDenton]

Writing the final binary is the responsibility of the linker (in this case MSVC's link.exe) so not something Rust controls.

One thing you can try is opening up a native tools command prompt and compiling a simple C program using cl.exe. Does that have the same issue? If so you may need to report a minimal repo to the Visual Studio team.

[voltagex]

Bingo! (unfortunately)

Writing a hello world and compiling it with cl.exe inside the shared folder results in the same issue.

[voltagex]

https://developercommunity.visualstudio.com/t/exe-built-in-a-Windows-Sandbox-shared-pa/10340169

[voltagex]

"Our teams prioritize action on product issues with broad customer impact" sounds remarkably like "too niche, wontfix". Can the rustc detect and warn about this scenario? Maybe that's too niche, too.

[ChrisDenton]

Honestly that sounds like boilerplate to me. It's marked as under consideration so I do think it's worth waiting a bit to see if there's any decision.

I guess Rust could test the output file for the magic bytes that indicates an executable file (or at least that they're non-zero). But that might need a new issue to gather feedback on that plan.