Programm-Update: Dateien löschen

[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. :gruebel:

• 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?

[Delphi.Narium]

Du könntest eventuell eine Batchdatei mit ins ZIP packen, die alle Aufräumarbeiten durchführt und sich dann am Ende selbst löscht. Dein Programm müsste dann prüfen, ob die Batchdatei vorhanden ist. Wenn ja, wird sie ausgeführt. Dies führt dazu, dass beim ersten Programmstart einmal aufgeräumt wird.

Nachteil: Es wird quasi auf Ewig (bei jedem Programmstart) geprüft, ob die Batchdatei vorhanden ist.

[H.Bothur]

Zitat:

Zitat von Delphi.Narium (Beitrag 1517682)

Du könntest eventuell eine Batchdatei mit ins ZIP packen, die alle Aufräumarbeiten durchführt und sich dann am Ende selbst löscht. Dein Programm müsste dann prüfen, ob die Batchdatei vorhanden ist. Wenn ja, wird sie ausgeführt. Dies führt dazu, dass beim ersten Programmstart einmal aufgeräumt wird.

Nachteil: Es wird quasi auf Ewig (bei jedem Programmstart) geprüft, ob die Batchdatei vorhanden ist.

Wobei man den Nachteil ja beseitigen kann wenn er in der Ini-Datei / Registry ein "Dateien bereits gelöscht" führt.

Hans

[Delphi.Narium]

Zitat:

Zitat von H.Bothur (Beitrag 1517685)

Zitat:

Zitat von Delphi.Narium (Beitrag 1517682)

Du könntest eventuell eine Batchdatei mit ins ZIP packen, die alle Aufräumarbeiten durchführt und sich dann am Ende selbst löscht. Dein Programm müsste dann prüfen, ob die Batchdatei vorhanden ist. Wenn ja, wird sie ausgeführt. Dies führt dazu, dass beim ersten Programmstart einmal aufgeräumt wird.

Nachteil: Es wird quasi auf Ewig (bei jedem Programmstart) geprüft, ob die Batchdatei vorhanden ist.

Wobei man den Nachteil ja beseitigen kann wenn er in der Ini-Datei / Registry ein "Dateien bereits gelöscht" führt.

Hans

Ja, das schon, aber es bleibt für eine einmalige Aufgabe eine dauerhafte Prüfung erforderlich, ob die einmalige Aufgabe erledigt wurde.

Sinnvoller wäre eine Lösung, die automatisch einmalig ausgeführt wird und anschließend auch keine Prüfung mehr erfordert, ob sie nun ausgeführt wurde oder nicht.

[TUhr]

Hallo,

warum löschst Du die nicht beim Starten der neuen Software ?

MfG

[Gausi]

Zitat:

Zitat von TUhr (Beitrag 1517692)

warum löschst Du die nicht beim Starten der neuen Software ?

Das ist ja auch der Vorschlag von Delphi.Narium. Um ehrlich zu sein: auf diesen offensichtlichen Ansatz bin ich nicht gekommen, um dieses Problem für die Zip-Variante zu lösen. :oops:
Beim Installer fällt das jedoch auch wieder raus - denn wenn der Player nach c:\Programme\ installiert wird, dann kann man da nachträglich nichts mehr löschen (zumindest nicht ohne weiteres). Und natürlich hat man dann dauerhaft die Abfrage drin, ob das noch getan werden muss - aber ein Value aus der Ini-Datei zusätzlich auswerten sollte den Start nicht verzögern. :lol:

D.h. es wird wohl eine Kombination aus "Installer räumt beim Installieren auf" und "exe aus der Zip räumt beim ersten Start auf". Ob letzteres ne Batchdatei wird, oder eine kleine eincompilierte Stringlist, deren Einträge in einer Schleife gelöscht werden, muss ich nochmal schauen.

Falls noch jemand andere Vorschläge hat - immer her damit. 8-)

[himitsu]

Wenn du kein Setup nutzt, welches das löschen könnte,
dann mach es doch einfach beim nächsten Start des Programms.

[edit] ups, vergessen zu aktualieren :freak:

[Delphi.Narium]

Wenn Du eine Stringliste einkompilierst könntest Du eventuell auch diesen Ansatz erweitern.

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.

Damit ist nach dem ersten Start von NEMP.EXE aufgeräumt und für die Zukunft keine weitere Prüfung erforderlich.

Ob das Löschen der eigenen EXE, das Umbenennen einer zweiten EXE auf den eigenen Dateinamen und deren anschließender Start so ohne weiteres möglich ist, weiß ich nicht. Habe das zwar schonmal realisiert, aber es hat nicht immer zwingend funktioniert.

Das Problem kann man aber mit Hilfe einer temporären Batchdatei lösen.

NEMP.EXE räumt auf.
Erstellet Batchdatei.
Startet Batchdatei.
Beendet sich.
Batchdatei löscht NEMP.EXE
Batchdatei benennt NEMP_NEU.XXX um
Batchdatei startet NEMP.EXE
Batchdatei löscht sich.

Gorb sowas:

Code:

:REM Fuenf Sekunden Pause machen, damit NEMP Zeit zum Beenden hat.
@PING -n 5 127.0.0.1 > nul
:REM Das Aufraeumprogramm loeschen
@DEL NEMP.EXE
:REM Die neue EXE umbenennen
@REN NEMP_NEU.XXX NEMP.EXE
:REM und dann starten, 
:REM damit die Batchdatei nicht bis zum Beenden von NEMP.EXE
:REM weiter laeuft, wird per START gestartet.
@start NEMP_NEU.XXX
:REM Batchdatei loescht sich selbst.
@DEL %0

Wenn die Batchdatei minimiert per ShellExecute gestartet wird, sollte das, aus Anwendersicht, unbemerkt ablaufen, lediglich der erste Start wirkt verzögert.

Eine "dauerhafte Aufräumänderung" des eigentlichen Programmes oder eine "dauerhafte Aufräumprüfänderung" im Player wäre damit entbehrlich.

[Uwe Raabe]

Zitat:

Zitat von Delphi.Narium (Beitrag 1517700)

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.

[himitsu]

Zitat:

PING

https://learn.microsoft.com/de-de/wi...mmands/timeout

[Delphi.Narium]

Zitat:

Zitat von Uwe Raabe (Beitrag 1517701)

Zitat:

Zitat von Delphi.Narium (Beitrag 1517700)

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:

Zitat von Delphi.Narium (Beitrag 1517703)

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

einfach das Admin-Manifest ins Programm :stupid: :freak:

[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:

Zitat von Delphi.Narium (Beitrag 1517700)

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
  
  Delphi-Quellcode:

  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 ... :stupid:

[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:

Zitat von Gausi (Beitrag 1517679)

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. :gruebel:

• 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:

Zitat von Jasocul (Beitrag 1517719)

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:

Zitat von Sinspin (Beitrag 1517721)

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. :thumb:

[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.

[himitsu]

Der billige Weg, (einfache) User vom Entpacken irgendwelcher ZIPs abzuhalten, ist

nenn sie nicht ZIP :stupid:

[Delphi.Narium]

Sinn einer portablen Version ist aber doch eigentlich, dass der User selbst entscheidet, wo er die Software "hinhabenwill", also eben, die Software nicht zu installieren, sondern "manuell irgendwo unterzubringen". Dazu ist halt die ZIP da, wenn man eben nicht per Setup installieren möchte.

Da hilft dann das Umbenennen der ZIP auch nicht, um das Problem mit dem Entfernen obsolet gewordenen Dateien zu lösen.

[generic]

Generell würde ich Software IMMER als MSI verteilen.

Unabhängig davon, kannst du CreateFile auch Parameter mitgeben, welche eine Datei automatisch löschen, wenn alle Dateizeiger drauf geschlossen wurden.
"FILE_FLAG_DELETE_ON_CLOSE"

Also Ausführungsprogramm ins %temp% kopieren mit CreateFile(mit FILE_FLAG_DELETE_ON_CLOSE), dann Starten und dann ursprüngliches Programm beenden.

[haentschman]

Moin...8-)

Zitat:

Sinn einer portablen Version ist aber doch eigentlich, dass der User selbst entscheidet, wo er die Software "hinhabenwill", also eben, die Software nicht zu installieren, sondern "manuell irgendwo unterzubringen". Dazu ist halt die ZIP da, wenn man eben nicht per Setup installieren möchte.

:gruebel: Bei welchem (normalem) Setup kann man nicht den Pfad festlegen? Setup ist doch kopieren + die Deinstallieren / Setup Einträge erstellen...Kann man dem Innosetup beibringen, das er nicht die Einträge für das Deinstallieren etc. erzeugen soll sondern nur kopieren?

[Sinspin]

Zitat:

Zitat von generic (Beitrag 1517766)

Generell würde ich Software IMMER als MSI verteilen.

Zitat:

Zitat von haentschman (Beitrag 1517769)

:gruebel: Bei welchem (normalem) Setup kann man nicht den Pfad festlegen? Setup ist doch kopieren + die Deinstallieren / Setup Einträge erstellen...Kann man dem Innosetup beibringen, das er nicht die Einträge für das Deinstallieren etc. erzeugen soll sondern nur kopieren?

Der MSI Installer schreibt Müll ins System. Andere Installer vermutlich auch. Zudem braucht man Admin Rechte um was zu installieren.

Portable Versionen brauchen keine Admin Rechte und schreiben auch nichts einfach irgendwo ungefragt hin.
Die Leben in ihrem Verzeichnis, zum Beispiel auf einem externen Datenträger. Und laufen auf jedem Rechner wo man sie haben will.

Außerdem, es ist oft hilfreich wenn man einen Thread vom Anfang ließt. Es geht hier nicht ansatzweise Sinnfälligkeit / -losigkeit von Installern. Sondern nur um die Lösung des im ersten Post beschriebenen Problems!

[KodeZwerg]

Na dann Entwickle doch ein kleines Tools was durch deine Verzeichnis-Struktur wandert, jede Datei in einer Liste aufnimmt und mit einer internen Liste abgleicht, alles was nicht reingehört zur jetzigen Version Liste auf (vielleicht mit einer CheckBox pro Eintrag) und habe einen "Entfernen" Button der ggf sich Admin-Rechte einholt um diese Dateien zu löschen. Innerhalb Nemp kannst Du das ja ggf. als Menu Punkt integrieren, sowas wie "Integritätscheck" o.ä....
Somit liegt es beim User, ob oder ob nicht... das sollte dann nicht mehr Deine Sorge sein.
(und dein eigentliches Nemp braucht nicht stets und ständig nach irgendwas suchen...)

[CCRDude]

Zitat:

Zitat von haentschman (Beitrag 1517769)

Kann man dem Innosetup beibringen, das er nicht die Einträge für das Deinstallieren etc. erzeugen soll sondern nur kopieren?

Logo, verwende ich regelmässig für kleine nachgeladene Updates.

Code:

[Setup]
Uninstallable=false

[Gausi]

Um das Thema nicht so in der Luft hängen zu lassen: Nach einigem hin und her (und einer längeren Programmier-Pause) habe ich nun einen Dialog halbwegs fertig, der bei Bedarf beim ersten Start angezeigt wird und über das Problem informiert. Bei der Anzeige des Dialogs wird ein Ini-Eintrag "LastUpdateCleaningCheck" passend gesetzt, der dann als einziger bei den folgenden Programmstarts getestet wird, damit der Dialog nicht jedes Mal angezeigt wird.
Nach erfolgreichem Löschen aller Dateien und Verzeichnisse (bzw. wenn keine da sind) wird zusätzlich ein Eintrag "LastUpdateCleaningSuccess" gesetzt. Über diesen wird gesteuert, ob im Menü ein Eintrag zum Aufräumen des letzten Updates angezeigt wird oder nicht.

Das sollte so passen. Falls das automatische löschen nicht klappt, soll der User in die Hilfe gucken. Da steht dann u.a. was von Admin-Rechten und nicht-leeren Verzeichnissen.