RenameFile der laufenden Anwendung

[Scotty]

Ich habe einen Auto-Updater in mein Programm eingebaut, der die laufende Anwendung per RenameFile() umbenennt. Das hatte auch funktioniert und geht auch bei einem Testprogramm, aber meine Anwendung mag sich jetzt nicht mehr umbenennen. LastError ist 32, eine sharing violation. Hat jemand eine Idee, wo ich nach dem Fehler suchen könnte?

[shokwave]

Ich denke es wäre einfacher/eleganter die Updateroutine in ein externes Programm auszulagern und bei Programmstart prüfen ob Updates vorliegen.

-Hauptprogrammstart
-Update vorhanden?
-nein - Hauptprogramm laufen lassen
-ja - Updateprogramm starten - Hauptprogramm beenden

oder einfach nach dem herunterladen das Updateprogramm starten und Hauptprogramm schließen

[Scotty]

Der Benutzer wird es mir danken, kein zweites Programm irgendwo rumliegen zu haben. Wie dem auch sei: Es hat schon funktioniert und geht jetzt nicht mehr. Ich habe an allen denkbaren Compilereinstellungen gedreht, alle Threads deaktiviert und die Umbenennung gleich zu Beginn gemacht - kein Erfolg. Diese Kleinigkeiten machen letzten Endes 90% des Programmieraufwands aus. Was ich alles sinnvolleres hätte programmieren können...

[Socke]

Die Idee sich selbst zu ersetzen wird kaum verwendet, vielleicht auch wegen einiger Probleme. In der Regel ist es einfacher, das wie von shockwave vorgeschlagen ein zweites Programm zu starten.
Was den Benutzer angeht: der wird sich eher weniger darum sorgen, dass ein anderes Programm ein Fenster aufmacht und nur Update hinaus schreibt. Beispiele gibts wie Sand am Meer: Lazarus, Mozilla Firefox/Thunderbird/etc. Deine Lösung dürfte im Übrigen auch nur unter Linux funktionieren, da zumindest Windows das bearbeiten von Exe-Dateien, die gerade ausgeführt werden, verbietet.

[Scotty]

da zumindest Windows das bearbeiten von Exe-Dateien, die gerade ausgeführt werden, verbietet

Dem ist nicht so.

Code: Alles auswählen

procedure TForm1.ButtonOnClick(..);
  RenameFile(Application.ExeName,ChangeFileExt(Application.ExeName,'.bak'));

[Socke]

da zumindest Windows das bearbeiten von Exe-Dateien, die gerade ausgeführt werden, verbietet

Dem ist nicht so.

Wenn ich ein Programm starte und versuche die Exe umzubennen, erhalte ich die Fehlermeldung: "<Programmname> kann nicht umbenannt werden: Die Datei wird von einer anderen Person bzw. einem anderen Programm verwendet. [...]"
Ich habe dazu extra mein Win XP SP2-Rechner eingeschaltet Welches Windows benutzt du denn?

[af0815]

Ich habe dazu extra mein Win XP SP2-Rechner eingeschaltet Welches Windows benutzt du denn?

Ich würde auch sagen, was für Virenschutz verwendet ihr Austausch/Umbennung wird von Schutzprogrammen zum Härten des Systems gerne verhindert.

[Hitman]

Die Exe kann sich nicht selbst verändern (umbenennen eingeschlossen), aber sich selbst lesen. Meine Lösung für Selbst-Updates läuft daher darauf hinaus, dass die Exe sich selbst kopiert (MeineAnwendung.exe --> MeineAnwendung.new) und dann per CreateProcess/TProcess diese "MeineAnwendung.new" mit dem Parameter "-selfupdate" aufruft. In meiner Anwendung prüf ich am Anfang einfach, ob ParamStr(1) = '-selfupdate' ist, und lasse die Anwendung sich dann wieder über ihren normalen Dateinamen drüber kopieren (MeineAnwendung.new --> MeineAnwendung.exe). Ist der erste Parameter anders/nicht vorhanden, prüfe ich, ob eine MeineAnwendung.new existiert, und lösche sie dann.
Der gesamte Update Prozess läuft dann z.B. so:

• Anwendung startet, ohne Parameter, auch keine .new Datei vorhanden
• Sie findet eine neue Version (z.B. per Checksum) und lädt diese als "MeineAnwendung.new" herunter
• Dann startet sie "MeineAnwendung.new -selfupdate" und beendet sich selbst
• MeineAnwendung.new stellt den Parameter -selfupdate fest, und kopiert sich selbst über "MeineAnwendung.exe"
• ... diese wird dann aufgerufen und MeineAnwendung.new beendet sich wieder (anstatt Hauptformular etc. anzuzeigen)
• MeineAnwendung.exe merkt nun, sie wurde ohne Parameter gestartet aber sie findet eine MeineAnwendung.new, welche sie nun löscht
• Danach geht der Start wie gewohnt weiter.

Alternativ könnte man statt des Parameters die Anwendung auch einfach prüfen lassen, ob ExtractFileExt(ParamStr(0)) = '.new' ist.
Viele Wege führen nach Rom

[Socke]

@Hitman: für das Betriebssystem sind das dann zwei verschiedene Programme, die sich gegenseitig erstellen/ersetzen. Aber es sollte funktionieren.

Ich würde auch sagen, was für Virenschutz verwendet ihr Austausch/Umbennung wird von Schutzprogrammen zum Härten des Systems gerne verhindert.

Ich verwende mit Windows XP SP2 nur ein Anti-Sicherheitsprogramm, da ich für alles andere außer Spielen ausschließlich Linux verwende.

[marcov]

Ich habe dazu extra mein Win XP SP2-Rechner eingeschaltet Welches Windows benutzt du denn?

Ich würde auch sagen, was für Virenschutz verwendet ihr Austausch/Umbennung wird von Schutzprogrammen zum Härten des Systems gerne verhindert.

+1. Windows hält immer Filelocks ein bisschen zu lange, aber Virenschutz usw macht das schlimmer.

[Scotty]

Welches Windows benutzt du denn?

XP in einer VirtualBox ohne Virenschutz.
Nur der Explorer hält die Hand auf laufende Anwendungen. Ich glaube, dass schon ein Batch Script ausreicht, aber das Testprogramm funktioniert definitiv wie beschrieben. Allerdings ist, abgesehen vom Thread-Thema, der Virenschutz sicher ein gutes Argument für ein alternatives Vorgehen.

CreateProcess/TProcess diese "MeineAnwendung.new" mit dem Parameter "-selfupdate"

So ähnlich werde ich das wohl auch machen. Mir gefällt aber das *.new nicht. Wenn ein Anwender das Zip manuell herunter lädt, soll er/sie genauso damit umgehen können, wie ich aus dem laufenden Programm. Also werde ich entweder das Zip in ein spezielles Verzeichnis entpacken oder beim Auspacken umbenennen.

Interessanter Weise hatte ich eine Version mit meiner Prozedur schon online gestellt, und Leute mit XP, Vista und Seven waren zufrieden mit dem Updateprozess. Da sind sicher viele mit Virenscannern, Firewalls und "was weiß ich nicht alles" dabei. Mich wundert es deswegen, dass Änderungen an einer anderen Stelle (Einbau von Sounds, Überarbeitung eines Threads) Probleme bereiten sollen. Ich werde noch ein, zwei Ideen prüfen.

PS: Der Debugger muss deaktiviert werden: Compilereinstellungen > Linken > -g, -gl