Harden installer activation against ACC file locks

This commit is contained in:
2026-08-11 15:37:52 +02:00
parent b32cc61e43
commit 08626197be
15 changed files with 389 additions and 23 deletions
+6 -2
View File
@@ -51,11 +51,13 @@ Der Installer verändert eine bestehende Installation erst nach erfolgreicher Pa
2. Die neue Version wird in ein eindeutiges Staging-Verzeichnis kopiert und dort mit `--self-test` geprüft.
3. Eine laufende Toolinstanz blockiert das Update.
4. Die bestehende Installation wird in ein Backup-Verzeichnis verschoben.
5. Das validierte Staging wird auf demselben Volume aktiviert.
5. Das validierte Staging wird auf demselben Volume aktiviert. Atomare Verzeichnisverschiebungen werden bei `IOException` oder `UnauthorizedAccessException` mit begrenztem Backoff bis zu achtmal versucht (insgesamt höchstens 19,75 Sekunden Wartezeit).
6. Die aktivierte EXE führt den Self-Test erneut aus.
7. Erst danach werden Verknüpfungen und Windows-Uninstall-Eintrag aktualisiert.
Schlägt ein Schritt nach Beginn der Umschaltung fehl, entfernt das Setup die neue Version und stellt das Backup wieder her. Tritt der Fehler bereits bei Paketprüfung oder Staging auf, meldet das Setup ausdrücklich **Kein Rollback erforderlich**, weil die aktive Installation unverändert blieb. Staging und Backup werden anschließend bestmöglich bereinigt. Kann ein nicht mehr benötigtes Backup wegen einer Dateisperre nicht gelöscht werden, bleibt die erfolgreiche Installation aktiv und das Log kennzeichnet den Abschluss als `success_with_backup_cleanup_warning`.
Bei einer Neuinstallation ohne bestehendes Ziel darf der Installer nach vollständig ausgeschöpften Move-Versuchen auf eine verifizierte Kopie zurückfallen. Dabei wird jede Datei aus dem bereits geprüften Staging nochmals gegen ihren Manifest-SHA-256 geprüft; anschließend läuft auch der zweite Self-Test aus dem endgültigen Ziel. Dieser Fallback gilt ausdrücklich nicht für Updates: Kann dort die Vorversion nicht atomar ins Backup verschoben werden, bricht das Update unverändert ab.
Schlägt ein Schritt nach Beginn der Umschaltung fehl, entfernt das Setup die neue Version und stellt das Backup wieder her. Tritt der Fehler bereits bei Paketprüfung oder Staging auf, meldet das Setup ausdrücklich **Kein Rollback erforderlich**, weil die aktive Installation unverändert blieb. Staging und Backup werden anschließend bestmöglich bereinigt. Kann ein nicht mehr benötigtes temporäres Verzeichnis wegen einer Dateisperre nicht gelöscht werden, bleibt die erfolgreiche Installation aktiv und das Log kennzeichnet den Abschluss als `success_with_temporary_cleanup_warning`.
## Installer-Diagnose
@@ -75,6 +77,8 @@ Die Abschlussmeldung enthält einen stabilen Fehlercode und die betroffene Phase
Das Log enthält Betriebssystem, Prozess-/OS-Bitness, .NET-Version, Rechner, Windows-Identität und Elevation sowie Installationspfade, freien Speicher, Dateigrößen, Versionen und SHA-256. Für Self-Tests werden Laufzeit, Exitcode dezimal und hexadezimal sowie vollständiges `stdout` und `stderr` geschrieben. Bei Fehlern folgen Exception-Kette, HRESULT und Stacktrace; jeder Rollbackschritt und sein Ergebnis werden separat protokolliert. Passwörter oder Verbindungsdaten werden vom Installer nicht verarbeitet oder geloggt.
Bei einer gesperrten Verzeichnisverschiebung erscheinen `event=directory_move_retry` und nach einer Erholung `event=directory_move_recovered`. Eine Neuinstallation mit Kopierfallback protokolliert `event=activation_fallback_started`, `event=activation_fallback_complete` und im Abschluss `activation_method=verified_copy_fallback`. Ein dauerhaft gesperrtes Update verwendet keinen Kopierfallback und endet weiterhin mit `SETUP-ACTIVATION`, bevor die aktive Version verändert wurde.
Für eine Supportanalyse bitte sichern:
1. Vollständige Fehlermeldung einschließlich Fehlercode und Phase.