emrg: fix Windows installer DeleteFile code 5 — module-holder enumeration + isolated mode - #844
Conversation
…tion + isolated mode (rants 2026-08-18T16:09:45/16:24:01)
argszero
left a comment
There was a problem hiding this comment.
✅ LGTM — cycle (1/3). Both test + test-windows CI PASS (run 32116928996). Reviewed full diff: module-holder enumeration via Get-Process/.Modules (only detector for DLL image-section locks, per host diagnostic evidence PID 9280), taskkill /F /T tree kill, verify module-holder category primary + createfile-probe demoted (supplementary), -I isolated mode in PrepareToInstall (self-lock), self-lock final guard. Local pytest 941 passed + 1 skipped (942 collected), GUI green, import + CLI OK.
argszero
left a comment
There was a problem hiding this comment.
✅ LGTM — cycle (2/3). Independent re-verify: head 96ef83f unchanged, CI test + test-windows both PASS (run 32116928996), MERGEABLE CLEAN. Confirmed in diff: find_install_module_holders()/_parse_module_holders()/_kill_tree_windows() present; stop_lock_owners runs module-holder enumeration before RM; verify has module-holder category before RM re-scan; createfile-probe demoted to supplementary; PrepareToInstall runs python with -I isolated mode; self-lock guard (no external module-holder/RM owner → WARNING + exit 1).
Summary
Fixes the persistent Windows installer DeleteFile code 5 on
~/.emrg/installoverwrite (host rants 2026-08-18T16:09:45 + 16:24:01, reproduced on v0.2.48).Root causes (diagnostic-script proof, rant 16:24:01)
install\lib\websockets\speedups.pyd(inherited PYTHONPATH). Restart Manager never reported it (the 2 owners it found were excluded ancestors) → killing the wrong object.DELETE + SHARE_NONEprobe reported OK whileDeleteFilestill failed — LoadLibrary image-section locks are only visible viaProcess.Modulesenumeration.stop_all.pyran frominstall\python-dist\python.exewhose site config could importinstall\lib→ potential self-lock (rant 16:09:45).Stop-Processhangs on refusing/waiting targets).Fixes (
emrg/_stop_all.py+packaging/make-installer.sh)find_install_module_holders()— PowerShellGet-Process+$_.Modules.FileNamefiltered by the install prefix: names the actual processes holding DLL/.pyd locks (with loaded-file list, parent PID, excluded-ancestor tag).stop_lock_owners()order — module-holder enumeration FIRST (kills each external holder's process tree viataskkill /F /T /PID), then Restart Manager as auxiliary; browser-harness hint preserved.verify— newmodule-holderresidual category (primary);RM re-scan+createfile-probekept as auxiliary; any external holder → exit 1 with a named list → installer aborts cleanly.createfile-probedemoted to supplementary — relabeled from the misleading "lock-probe 0 locked" (it cannot see DLL locks); real verdict comes from module-holders."{PythonExe}" -I "{StopScript}"(ignore PYTHONPATH/site-packages/.pth), so the pure-stdlib script never importsinstall\lib(self-lock eliminated).WARNING: lock holder is the stop_all runtime itself+ exit 1 (re-run installer guidance) instead of letting the installer hit code 5.Verification
tests/test_stop_all.py+tests/test_installer_stop.py: 85 passed (new tests pin module-holder enumeration,taskkill /F /T, verify category order, createfile-probe demotion, self-lock guard).npm testgreen; import + CLI OK.Acceptance (Windows, next release)
stop_all.logshowsmodule-holders: PID ... python.exe (...browser_harness.daemon) loads [speedups...]→ killed with its tree → verify has no module-holder → installer overwritesinstall\without code 5. Clean/quiet installs unaffected; rm-scan owner detail retained.