Flow
Install and uninstall with a record
1Check
If the file is there but will not load, stop and change nothing.
2Record
On first install, save the old value of each thing you touch, or note it was missing.
3Write
Write a temporary file, then rename it over the real one.
4Undo
Put the old values back, and ask if the user changed yours.
5Test
Install, uninstall, and compare with how the file started.
Without checking it first, the uninstall command turns off a setting. I shipped it like that.
My tool hooks AI coding tools up to my monitoring service. This change added one more. Install opens that tool's settings file, turns its telemetry switch on, adds a sender that points at my service, puts my key in it, and saves. Uninstall turns the switch off, deletes the sender, and saves. No tests came with it.
Install never writes down what was there first. So uninstall can't put it back. It just sets the values it thinks are right.
The guess
Install does leave the rest of the file alone. It only owns two things: the on switch and one sender slot. But if the user already had telemetry on, uninstall turns it off. If they had their own sender in that slot, it's gone for good. Only a file that started empty comes out clean.
A typo becomes a blank file
If the file is there but won't load, install warns, starts from nothing, and saves over it. One stray comma and the user loses every setting. If you can't read a file, stop and leave it alone.
Every rerun is another install
Other commands run the same code, like setting a new key. Each time, telemetry goes back on. So if you save a record of the old state, save it once, on the first install, or you'll just record your own values.
Two copies of a key
The key goes in twice, in plain text. Uninstall deletes both but doesn't say the key still works on the service.
Failures that still count as success
If uninstall fails, it warns and marks the tool removed anyway. The user's file still points at my service. And both paths write straight over the file, so a crash can leave half a file behind.
What I'd write instead
If you're building an installer that edits someone else's settings, these are the steps I'd follow:
- on first install, save the old value of everything you touch, or note it was missing
- refuse to run on a file that won't load
- write to a temporary file, then rename it into place
- on uninstall, put the old values back, and ask if the user changed yours
- mark the tool removed only after the write works
Then test the round trip: install, uninstall, and compare with how the file started. For a tool that only touches two values, that's a short test to write, and it didn't ship with the change.