From 2c014fd7525ab7b14f324697a2498951f337d8ea Mon Sep 17 00:00:00 2001 From: Josh Knapp Date: Mon, 10 Aug 2026 07:52:34 -0700 Subject: [PATCH] CI: create the WOW64 junctions in the workflow instead of by hand MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The Windows fix was the only part of it living outside git — two junctions created by hand on the build VM. Rebuild that VM, add a second Windows runner, or reset the SYSTEM profile and Windows builds break again with an error that points nowhere near the cause. Tauri downloads candle.exe, light.exe and makensis.exe, and all three are 32-bit. A runner running as SYSTEM has %LOCALAPPDATA% under C:\Windows\System32\config\systemprofile, and WOW64 redirection serves 32-bit processes reading System32 from SysWOW64, where those directories do not exist. The bundlers cannot see their own folder: candle exits 0x80131700, makensis reports "Unable to start child process, error 0x2", and Tauri surfaces neither — only "failed to run candle.exe". The job now junctions the SysWOW64 view onto the System32 originals when it detects a profile inside System32, and skips entirely otherwise, so a runner running as a normal user is unaffected. Idempotent, and written with goto rather than nested blocks to avoid the delayed-expansion trap that already bit the MSVC step. Verified rather than assumed: the hand-made junctions were deleted from the build VM before this was pushed, so this run has to recreate them. Co-Authored-By: Claude Opus 5 (1M context) --- .gitea/workflows/build-app.yml | 33 +++++++++++++++++++++++++++++++++ 1 file changed, 33 insertions(+) diff --git a/.gitea/workflows/build-app.yml b/.gitea/workflows/build-app.yml index aa05136..56ffaee 100644 --- a/.gitea/workflows/build-app.yml +++ b/.gitea/workflows/build-app.yml @@ -395,6 +395,39 @@ jobs: ) endlocal + - name: Work around WOW64 redirection for 32-bit bundlers + shell: cmd + run: | + rem Tauri downloads its bundlers - candle.exe, light.exe and + rem makensis.exe - and every one of them is 32-bit. When the runner + rem runs as SYSTEM its %LOCALAPPDATA% is under + rem C:\Windows\System32\config\systemprofile, and WOW64 redirection + rem serves any 32-bit process reading System32 from SysWOW64 instead - + rem where those directories do not exist. The bundlers then cannot see + rem their own folder: candle exits 0x80131700 and makensis reports + rem "Unable to start child process, error 0x2". Tauri surfaces neither, + rem only "failed to run candle.exe", which is why this is worth a + rem comment this long. + rem + rem Junctioning the SysWOW64 view onto the System32 originals makes the + rem redirected path resolve to the same files. A runner running as a + rem normal user has a profile outside System32 and skips all of this. + echo.%LOCALAPPDATA%| find /I "\system32\" >nul + if errorlevel 1 goto skipwow + + if not exist "%WINDIR%\System32\config\systemprofile\AppData\Local\tauri" mkdir "%WINDIR%\System32\config\systemprofile\AppData\Local\tauri" + if not exist "%WINDIR%\SysWOW64\config\systemprofile\AppData\Local" mkdir "%WINDIR%\SysWOW64\config\systemprofile\AppData\Local" + if not exist "%WINDIR%\SysWOW64\config\systemprofile\AppData\Local\tauri" mklink /J "%WINDIR%\SysWOW64\config\systemprofile\AppData\Local\tauri" "%WINDIR%\System32\config\systemprofile\AppData\Local\tauri" + + if not exist "%WINDIR%\System32\config\systemprofile\.cache" mkdir "%WINDIR%\System32\config\systemprofile\.cache" + if not exist "%WINDIR%\SysWOW64\config\systemprofile\.cache" mklink /J "%WINDIR%\SysWOW64\config\systemprofile\.cache" "%WINDIR%\System32\config\systemprofile\.cache" + + echo WOW64 junctions in place for the SYSTEM profile + goto :eof + + :skipwow + echo Runner profile is outside System32 - WOW64 junctions not needed + - name: Install Rust stable run: | where rustup >nul 2>&1 && (