Figure out how to deal with the "Restart to repair drive errors"
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:
- After the build, request the daemon run
chkdsk
on a VHD from the client. - 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.
- 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!) - After
chkdsk.exe
completes, the daemon unmounts the VHD and returns the output ofchkdsk
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
.