Programm-Update: Dateien löschen

[Delphi.Narium]

Zitat von Uwe Raabe:

Zitat von Delphi.Narium:

Das Programm räumt beim Start auf, löscht die eigene EXE (also NEMP.EXE), benennt NEMP_NEU.XXX um in NEMP.EXE und startet diese.

Funktioniert eventuell aber auch nur mit Admin-Rechten.

Bei 'ner portablen Version würd' ich das eher nicht erwarten, zumindest hab' ich die immer auf 'nem externen Datenträger und nicht in dem Bereich, bei dem Windows die Rechte etwas strenger kontrolliert.

Frei nach dem Motto: In einem Verzeichnis, in das ich 'ne ZIP extrahieren kann, hab' ich wohl Schreibrechte und kann dann dort (hoffentlich) auch Dateien löschen.

Aber: Eine zwingend immer funktionierende Lösung des Problemes wird es nicht geben.

Auch das Löschen von Dateien aus dem Programm heraus ist (ebenfalls aus Rechtegründen) nicht zwingend möglich. Dann würde das Programm bei jedem Start versuchen die Dateien zu löschen und dabei scheitern oder man müsste sich "irgendwo" merken, dass der erste Versuch fehlgeschlagen ist und man weitere Versuche dann unterlässt.

[himitsu]

Zitat von Delphi.Narium:

Aber: Eine zwingend immer funktionierende Lösung des Problemes wird es nicht geben.

einfach das Admin-Manifest ins Programm

[Dalai]

Meiner Meinung nach kann man sich für eine portable "Installation" schon die Frage stellen "Kann man dem Anwender einer portablen Anwendung zumuten, nach dem Entpacken ein Skript auszuführen?". Wenn die Antwort darauf "Ja" lautet, würde ich einfach ein Skript zusammenbasteln, das die nötigen Aufgaben erledigt, in diesem Fall nicht mehr benötigte Dateien löscht. Selbst mit einem Batchskript kann man sowas recht komfortabel machen:

Code:

@echo off
setlocal

set "files=somefile.exe someotherfile.txt someold.dll"

for %%F IN (%files%) DO (
    if exist "%~dp0%%~F" (
        echo Deleting "%~dp0%%~F"
        del "%~dp0%%~F"
    )
)
endlocal

Die Liste der Dateien kann man einfach erweitern/bearbeiten.

Für die reguläre Installation übernimmt diese Aufgabe natürlich das Setup.

Grüße
Dalai

[Gausi]

Zitat von Delphi.Narium:

Deine Programm heißt NEMP.EXE.
Die bisherige NEMP.EXE benennst Du im ZIP um, z. B. NEMP_NEU.XXX.
Du erstellst ein neues Programm NEMP.EXE für die Aufräumarbeiten.
Diese Programm wird der Anwender (gewohnheitsgemäß, per ShortCut, Link, ...) starten.
Das Programm räumt beim Start auf, löscht die eigene EXE (also NEMP.EXE), benennt NEMP_NEU.XXX um in NEMP.EXE und startet diese.

Das sind so Tricksereien, die ich eigentlich vermeiden will. Wenn man das für den Anwender transparent macht, und ihm sagt "Hör mal, ruf bitte das CleanUp-Tool auf, weil der Entwickler früher Murks programmiert hat ein paar Dutzend Dateien doppelt und dreifach auf die Platte kopiert hat ..." - oder halt ein CleanUp-Script wie das von Dalai, dann fände ich das eine solide Möglichkeit, die ich mir auch nochmal näher durch den Kopf gehen lassen werde.

Mein aktueller Plan sieht aber so aus, das direkt in der eigentlichen exe zu machen:

• Neue Unit, die im Wesentlichen besteht aus
  const OutdatedFiles: Array[0..30] of String = ( ...); und einer Prozedur DoCleanUp
• einen Eintrag in der Ini: LastCleanUpVersion=...
• eine Abfrage
  
  Delphi-Quellcode:

  if (LastCleanUpVersion < NeededCleanUpVersion) then begin
    DoCleanUp; // ggf. mit Frage an den Benutzer? ggf. Aufruf-Möglichkeit später im Einstellungsdialog an geeigneter Stelle?
    UpdateIni; // auf jeden Fall, egal obs erfolgreich war oder nicht. Im Zweifel: RTFM!
  end;

Wenn ich das richtig sehe, kommt beim regulären Startvorgang dann ein Aufruf von Ini.ReadInteger/String hinzu, sowie ein Vergleich (ob ich da nun ein Integer nehme, oder ein String mit Major.Minor.Patch ist ja auch wurscht).

Beim Start werden aktuell an halbes Dutzend Plugins für die bass.dll geladen, eine mehrere MB große Binärdatei geparsed, daraus mehrere verschachtelte Dictionaries mit zehntausenden Einträgen erstellt - da ist das vollkommen egal. Eine ähnliche Abfrage habe ich ja auch für den Start des "Wizards" drin, der einmalig einige Opt-In-Einstellungen abfragt. (Das dann inklusive Zeug wie "Die Einstellung, dass der Wizard gestartet wurde, kann gespeichert werden.")

Und etwas überflüssiger Code wegen ein paar Strings und einer File-Delete-Routine? Ja nu. Der Player überprüft bei jedem Abspielen die Dateigröße der mp3 auf einen ganz bestimmten Wert, berechnet im Zweifel die MD5-Hashsumme der Datei, und wenn diese einen ganz bestimmten Wert hat, dann wird die mp3-Datei in ihre einzelnen Frames zerlegt, die Audiodaten (abzüglich der mpeg-Header) als Brainfuck-Programm interpretiert, das eine neue mp3-Datei auf Platte schreibt und diese dann anstelle der eigentlichen Datei abspielt ...

[Delphi.Narium]

Ok, dann kann man auch jedes Mal nachgucken, ob ein bestimmter Job irgendwann schon erledigt wurde oder eben nicht und ihn dann ausführen.

[KodeZwerg]

Zitat von Gausi:

Ich stehe vor der etwas blöden Situation, dass beim nächsten Update meines Players (ist noch ne ganze Weile hin, aber der problematische Teil in dem Kontext ist fast fertig) ein paar Dateien überflüssig werden. Die sollen dann weg. Problem ist, dass ich einerseits eine Setup.exe habe (da kann ich ja bei InnoSetup beim Installieren eine Liste von Dateien angeben, die ggf. vorher gelöscht werden sollen), aber auch ein einfaches Zip-Archiv zum entpacken und loslegen (portable Software, ohne Installation). Wenn der User da einfach das neue Archiv in das vorhandene entpackt, bleiben die alten Dateien natürlich erhalten.

Ich sehe da irgendwie keine wirklich schöne Lösung.

• Vorhandene Dateien durch Dummy-Dateien überschreiben (z.B. Bilder mit 1x1 Pixel, PDF mit "Outdated" als Inhalt) ist blöd - dann schleppe ich ständig Datenmüll auch im Zip/Setup mit.
• Vorhandene Dateien im Setup löschen lassen (und in der Zip-variante einfach beibehalten), ist blöd, weil einige Infos dann veraltet und verwirrend sind (z.B. eine überflüssig gewordene veraltete PDF)
• Oder ist hier das "Best practice", dem Zip-Anwender auf die Komplikationen hinzuweisen und ihm erklären, dass er einen bestimmten Ordner im Programm-Verzeichnis vor dem Upgrade löschen sollte? Und im Code die Verwendung der Dateien so anpassen, dass die alten Dateien den Programmablauf nicht stören können, falls sie doch da sind? Aber liest der normale Anwender sowas?

Wie macht ihr das?

1.
RarSfx Technik o.ä. zum Einsatz kommen lassen. (da kannst du befehle integrieren, ähnlich einem Setup.exe Programm)
Also RarSfx entpackt nach \xyz\ dein(e) archiv(e), auch eine "cleanup.bat", die .bat über RarSfx ausführen lassen, die .bat löscht alles was Du angibst, RarSfx löscht nach Abschluss die .bat.

oder

2.
Normales Archivformat (.zip/.7z/.rar/whatever) anbieten und User mitteilen das sie im Vorfeld den Verzeichniss Inhalt manuell löschen müssen.
(ich bin kein "Nemp" user, von daher weiß ich nicht ob du Konfigurations Dateien erstellst oder andere arten von Dateien... eventuell für so etwas ein backup&restore tool mit anbieten, du solltest dich ja in deiner Verzeichnis Struktur gut auskennen und wissen was von dir kommt und was user selbst erstellt haben...)

Wäre das eine Möglichkeit?

[Jasocul]

Für die Version mit dem regulärem Setup hast du bereits eine Lösung. Es geht also nur noch um die zip-Variante.
Anwendern, die diese verwenden, kann man eine gewisse Verantwortung übertragen. Mache eine passende Readme-Datei und ein Batchprogramm. Dann können die Anwender selbst entscheiden, wann aufgeräumt wird.

[Sinspin]

Zitat von Jasocul:

Es geht also nur noch um die zip-Variante.
Anwendern, die diese verwenden, kann man eine gewisse Verantwortung übertragen. Mache eine passende Readme-Datei und ein Batchprogramm. Dann können die Anwender selbst entscheiden, wann aufgeräumt wird.

Was anderes würde ich für eine portable Version auch nicht haben wollen. Deswegen verwende ich ja nicht das Setup was sich erlaubt irgendwelche geheimen Sachen auf meiner Platte anzustellen.

[Gausi]

Zitat von Sinspin:

Was anderes würde ich für eine portable Version auch nicht haben wollen. Deswegen verwende ich ja nicht das Setup was sich erlaubt irgendwelche geheimen Sachen auf meiner Platte anzustellen.

Da geht es mir ähnlich, deswegen stehe ich Vorschlägen wie der RarSfx-Idee auch eher kritisch gegenüber, auch wenn so ein "Setup light" durchaus interessant klingt.

So ganz ohne Automatismus möchte ich das aber auch nicht machen. Neulich hatte ich z.B. den Fall, dass jemand das Zipfile (das auch eine Datei enthält, die dafür sorgt, dass Einstellungen im Programmverzeichnis gespeichert werden sollen) unter c:\Programme entpackt hat, was dann dazu führte, dass keine Einstellungen und Daten gespeichert werden. Man sollte also nie die Fähigkeiten der User unterschätzen, etwas Unerwartetes zu tun.

Ich denke, ein Hinweis-Fenster beim ersten Start der neuen Version, das auf das Problem hinweist, ist ein guter Kompromiss zwischen "Kontrolle über die portable Version" und "Komfort". Wenn der User die Meldung wegklickt, bleibt der Hinweis ggf. an entsprechender Stelle im Einstellungsdialog erhalten, verbunden mit einem Button "Jetzt aufräumen", um das nachzuholen.

Ich bin nebenbei gesagt positiv überrascht über die zahlreichen Antworten. Hätte nicht gedacht, dass es dazu so viele Meldungen gibt.

[Sinspin]

Du könntest die Dateien auch sichtbar versionieren.
Vlt noch eine Datei, "Version.txt" die nur die Info enthält welche Version gerade Mode ist. Für die, die keine ReadMe lesen wollen.

Code:

Help.3_14.pdf
Help.3_15.pdf

Da wirkt sich allerdings nur bei neuen Nutzern direkt aus. Bei Bestandsnutzern musst Du darauf vertrauen dass sie die ReadMe lesen.