I did not want to replace an installed program relying only on the expectation that an update would work. First identify the executable to return to. Reading rollback preparation and installation records separates retaining an installer, verifying its bytes and restoring user data.
Source backup alone does not prepare executable rollback
Rebuilding source requires the matching dependencies and build conditions. Retaining the previous installer identifies a more concrete return deliverable. Installation records keep the preceding installer, source and payload hashes as separate evidence.
This preparation differs from restoring manuscripts and databases. Returning binaries to an old version does not automatically restore data changed meanwhile, and storage compatibility is another question. I do not compress program rollback and retained user work into one backup-complete label. A reviewer needs to know which file prepares for which failure before judging the return path.
An existing installer needs more than a promising name
PrepareRollbackInstaller checks that an existing installer is a regular file and compares source/copy hashes. When a corresponding receipt exists, version and installerSha256 are checked too. That receipt is optional in this branch, so not every existing file is necessarily authenticated by a trusted receipt.
Equal copy hashes establish that the same bytes moved; they do not establish the provenance of an official release. Trust in an existing path and actual executability need additional evidence. A function name cannot silently imply every kind of verification. Record the compared values and absent conditions rather than enlarge a byte check into a universal approval.
When missing, stage the installed payload separately
The missing-installer branch compares source package and installed versions, then reads allowed payload files from the installed directory. It does not copy the whole user store or login folders. Staged files are compared with original hashes, and both stage and installed payload are checked around the injected build operation.
The unit-test build writes a synthetic installer substitute. That test alone cannot prove successful actual NSIS restoration. Generated receipts and copy hashes retain the same limitation. A real restore and restart need separate integration evidence. Existence of a preparation path differs from completed recovery of an application.
Do not build a return path from an incomplete installation
Tests require no build when app.asar is missing and refuse packaging newer source as the old installed version. Tampering with a reusable installer produces hash mismatch. Failed rollback preparation must not be described as a normal reason to proceed to the new installation first.
The current product removed embedded repair runtime, so retained helper code and tests are not advertised as a present automatic self-repair feature. Historical design choices remain reusable, but active entry points need separate inspection. A retained preparation function does not establish that the current app automatically performs updates or repairs.
Keep preparation, application and recovery receipts distinct
A later actual installation record retains an initial safety refusal before normal shutdown finished, followed by application after closure. A prepared installer did not authorize touching work still running. Current state and preservation checks had to connect in sequence.
I executed no new installation or rollback for this article. The shared module only compares declared synthetic snapshots and digest strings; it is no restore utility. The reusable rule is to know the return bytes before change, inspect preservation afterward and separately verify any actual recovery. A prepared route and a successfully completed return are different outcomes that should retain different evidence.