fix: autostart works on a profile with no Run key - #445
Merged
Merged
Conversation
Closes #444. Found by the nightly acceptance run, two days after #426 wired it up. skrog: applying config: opening the Run key: The system cannot find the file specified. HKCU\Software\Microsoft\Windows\CurrentVersion\Run is created by Windows ON DEMAND. A profile that has never registered a logon entry does not have one -- the normal state of a fresh hosted runner, and of a new or freshly-imaged user profile. All three entry points used OpenKey, which fails with ERROR_FILE_NOT_FOUND when the key is absent: Enable could not register autostart at all Status returned an error, so `skrog status` and `doctor` failed Disable returned an error, contradicting its own doc comment -- "Removing an entry that does not exist is success: the user asked for a state, not an action." It handled a missing VALUE and not a missing KEY, which is the same answer one level up. The message compounded it: "cannot find the file specified" reads as a missing FILE and sends the user looking for skrogw.exe. Enable now uses CreateKey, the standard idiom for the Run key -- it opens an existing key unchanged, so it costs nothing where one is already there. Status reports "not registered" and Disable reports success, because an absent key is an answer rather than a failure. Why the tests did not catch it ------------------------------ From the existing helper: // The scratch key must exist for OpenKey(SET_VALUE) to succeed. k, _, err := registry.CreateKey(...) The test created the precondition the product assumed. That comment was the bug report, sitting in the file the whole time. useAbsentScratchKey is its opposite: it points at a key that does not exist and asserts it stays that way until the code under test creates it. Three tests use it, one per entry point. Verification ------------ Each fix controlled separately, and both reproduce the nightly failure verbatim: Enable back to OpenKey -> "Enable with no Run key: opening the Run key: The system cannot find the file specified." Status guard removed -> "Status with no Run key returned an error: opening the Run key: The system cannot find the file specified." Severity is real but narrow: most Windows profiles have the key. It bites a fresh profile, a hardened or imaged machine, and every clean CI runner -- which is exactly the headless-CI case the README sells.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #444. Found by the nightly acceptance run — two days after #426 wired it up.
HKCU\Software\Microsoft\Windows\CurrentVersion\Runis created by Windows on demand. A profile that has never registered a logon entry does not have one — the normal state of a fresh hosted runner, and of a new or freshly-imaged user profile. All three entry points usedOpenKey, which fails withERROR_FILE_NOT_FOUNDwhen the key is absent:EnableStatusskrog statusanddoctorfailedDisableDisablesays: "Removing an entry that does not exist is success: the user asked for a state, not an action." It handled a missing value and not a missing key, which is the same answer one level up.The message compounded it: "cannot find the file specified" reads as a missing file and sends the user looking for
skrogw.exe.Enablenow usesCreateKey— the standard idiom for the Run key, and it opens an existing key unchanged, so it costs nothing where one is already there.Statusreports "not registered",Disablereports success.Why the tests did not catch it
From the existing helper:
The test created the precondition the product assumed. That comment was the bug report, sitting in the file the whole time.
useAbsentScratchKeyis its opposite: it points at a key that does not exist and asserts it stays that way until the code under test creates it.Verification
Each fix controlled separately, and both reproduce the nightly failure verbatim:
Enableback toOpenKeyEnable with no Run key: opening the Run key: The system cannot find the file specified.Statusguard removedStatus with no Run key returned an error: opening the Run key: The system cannot find the file specified.Severity is real but narrow: most Windows profiles have the key. It bites a fresh profile, a hardened or imaged machine, and every clean CI runner — which is exactly the headless-CI case the README sells.