ospab 66368c9d0f fix(gui): helper task checked only its name, not the exe it points at ... A Scheduled Task stores an absolute path. Checking that a task named "OSTP TUN Helper" exists said nothing about whether its <Command> still points at the helper we are about to run, and the paths do drift: a dev build registers target\debug\ostp-tun-helper.exe, an installer registers Program Files, and moving or reinstalling the app leaves the old path behind. That failed silently in the worst way. schtasks /Run reports success for merely ACCEPTING the launch request — a task whose exe no longer exists fails afterwards, out of band, with nothing returned to us. So launch_as_admin returned Ok, and the caller then sat in its 60-second connect loop before reporting "Timeout connecting to helper." On every connect, permanently, with no way out except deleting the task by hand. The check now reads the registered <Command> back and compares it to the exe, re-registering through the existing /F overwrite when they differ: one consent prompt, once, instead of a permanent silent breakage. The path is read via /Query /XML rather than /FO LIST /V because the list format's field labels are localized — "Task To Run" is "Задача для запуска" on a Russian Windows — while XML tag names are not. schtasks emits UTF-16LE with a BOM there, which is decoded explicitly, with UTF-8 tolerated as a fallback. Both paths are canonicalized before comparison so casing, `..` and 8.3 short names do not read as a mismatch; a path that cannot be canonicalized no longer exists, which is itself grounds to re-register.		2026-08-07 22:24:40 +03:00
..
lib.rs	fix(gui): helper task checked only its name, not the exe it points at	2026-08-07 22:24:40 +03:00
main.rs	refactor(logging): consolidate all logs into one ostp.log, Windows clears on start	2026-07-09 14:32:08 +03:00