Figure out how to deal with the "Restart to repair drive errors"

[hach-que]

This is expected because the way we write files into the VHD is via a library (DiscUtils) instead of mounting the VHD and copying files across. Unfortunately, DiscUtils doesn't seem to set up "System Volume Information" up correctly, which causes Windows to give this misleading error notification when UEFS drives are mounted. They work totally fine at runtime, but you have to silence the error notification in the Windows notification area.

There's two paths to fixing this:

• Run chkdsk on the VHD after building it so that it's valid when it gets mounted downstream, or
• Use Windows to create the VHD instead of DiscUtils. This means the VHD has to be at least mounted from the daemon rather than handled inside uet uefs build, since the client won't have permission to mount directly.

Although chkdsk is a bit jank, I feel like it's the safer solution since the DiscUtils library lets us set the ACLs directly on files to "Everyone" as they're written, rather than having to jump through hoops with the Windows kernel to set ACLs correctly.

I think the logic for doing chkdsk will have to look a bit like this:

1. After the build, request the daemon run chkdsk on a VHD from the client.
2. The daemon mounts the VHD, but does so in the "please don't assign a drive letter mode". Hopefully this prevents Windows from warning about drive errors.
3. The daemon runs chkdsk.exe against the volume. It needs to invoke the command like so: chkdsk /F "\\?\Volume{volume-guid}" (without a trailing slash!)
4. After chkdsk.exe completes, the daemon unmounts the VHD and returns the output of chkdsk in the response.

If we find that chkdsk takes a while on the VHD, we might have to override the client deadline so that it can accept a long RPC call, or make it a streaming RPC call that returns the output of chkdsk.