A command-line installer adds specific tool permission rules to developer configuration during setup. When the installer later performs repair or uninstall operations, it must distinguish between permissions it added versus pre-existing user rules, including both allows and explicit denies. The challenge is maintaining an ownership journal that tracks which rules belong to the installer. Setup can crash between saving this journal and applying the settings changes, creating inconsistent state. What patterns ensure safe preservation of user permissions across install, repair, and uninstall workflows when the operation can be interrupted at any point?

New failure scenario: After installation completes, the developer manually modifies one of the installer-owned permission rules and edits unrelated settings. Then uninstall runs. Without additional verification, the ownership journal claims the rule but the current file content no longer matches what the installer wrote, creating ambiguity about whether to remove it.

Compare-before-remove solution: Before removing any journaled rule, verify that its current content in the settings file exactly matches the content recorded in the ownership journal at installation time. The journal must record not just rule identity but the exact text of each inserted rule. During uninstall, read the current settings file, locate each journaled rule by position or identifier, compare its current text to the journaled text, and only remove rules that still match exactly. If a rule has been modified, report an ownership conflict and leave it in place.

Ownership conflict reporting: When uninstall finds a rule in the journal but the current content differs, emit a diagnostic message identifying which rule has been modified and whether it was removed, changed, or moved. The conflict is informational only; uninstall never removes a modified rule. This preserves user intent when they edited an owned rule to customize it. The journal entry remains to track that the installer once owned that rule, but removal is skipped.

Partially completed uninstall recovery: Uninstall must be idempotent. If it crashes partway through removing rules, a subsequent uninstall run should safely complete the work. The ownership journal serves as the canonical intent record. Each rule removal is independent: match current text against journal, remove if unchanged, skip if modified or already absent. The journal itself is only deleted after all rule removals complete successfully. If uninstall crashes before removing the journal, the next run sees the same journal, re-evaluates each rule, and removes any that still match and are still present. Rules already removed are simply not found, which is the desired final state, so their absence is not an error.

Critical detail for crash safety: The journal must survive until all removals are verified complete. Update the journal at the end to mark completion, then delete it in a final step. If the process crashes before journal deletion, the next uninstall run treats it as a resumption and completes any remaining work. If it crashes after partial removals but before marking completion, the next run will attempt to remove all journaled rules again, but rules already removed will not be found, and compare-before-remove ensures no user-modified rules are touched.