Script nur 1x täglich starten (intervallgesteuert, NICHT zeitgesteuert)

Professor Bernd

Hallo,

ein Script/Exe soll nur 1x täglich ausgeführt werden. Dazu würde mich eure Meinung interessieren, wie ihr die Prüfung dazu am "geschmeidigsten" anlegen würdet.

Details

Ein Script hat eine Aufgabe, die es nur 1x täglich ausführen soll. Es wird beim User-Login automatisch gestartet und prüft ob die Aufgabe an diesem Tag schon ausgeführt wurde. Falls ja, beendet es sich sofort. Falls nein führt es seine Aufgabe aus und beendet sich dann. Es soll nur die Ausführung des aktuellen Tages geprüft werden. Wird es an einem oder mehreren Tagen nicht gestartet, sollen verpasste Ausführungen NICHT nachgeholt werden.

Also eigentlich sehr einfach gehalten.

Meine bisherigen Lösungen:

- Eine Datei mit dem aktuellen Datum wird erstellt.

- Ein Eintrag mit dem aktuellen Datum in der Registry.

- Ein Eintrag mit dem aktuellen Datum in einer INI-Datei.

Bei jeder dieser Lösungen wird beim Start des Scripts geprüft, ob eine Datei, bzw. ein Eintrag mit dem aktuellen Datum schon vorhanden ist.

Findet ihr eine/alle Lösung/en in Ordnung, oder habt ihr andere Ideen? Was würdet ihr bevorzugen? Fällt eine dieser Lösungen wegen den Win 10 Sicherheitseinstellungen aus? Muss ich sonst etwas beachten?

**Musashi**

Hallo Professor Bernd !

Loggen sich mehrere User an dem Rechner ein / läuft das Programm im Netz ?

Auf die Variante "Schreiben des aktuellen Datums in die Registry" würde ich verzichten. Hier kann es am ehesten zu Rechteproblemen kommen.

Könntest Du die Aufgabe des Skriptes näher beschreiben, nur damit man eine Vorstellung hat ?

Gruß Musashi

Professor Bernd

Das Script dient zur Steuerung eines anderen Programms (wahrscheinlich wird es 7-Zip). Damit wird von einem Quellverzeichnis ein Zip-Archiv mit dem Erstellungsdatum angefertigt. (Es wird mehrere Quellverzeichnisse und somit mehrere Zip-Dateien geben, aber der Einfachheit kann man hier von 1 ausgehen.)

Damit sich der Thread nicht so aufbläht, halte ich die Angaben knapp. Falls mehr von Nöten sind, reiche ich die gerne nach.

Kurz gesagt: Nur 1 User, nur lokale Funktionalität ohne Netzwerk.

Mein Bauchgefühl hat die Varianten "Registry" und "INI" schon runter gestuft. Danke für das Argument gegen die Registry! Gibt es bei der INI-Variante auch einen Haken? VirtualStore oder so?

Dann hatte ich noch eine andere Variante im Sinn, die ich aber verworfen habe. Die Backupdateien bekommen sowieso das Datum der Erstellung, das wollte ich dann prüfen. Aber das habe ich verworfen, da ich vom Gefühl her hier die meisten Fehlerquellen vermute. Nachtrag: Zum Beispiel wenn aus einem Grund die Zip-Datei nicht erstellt werden kann, dann wird vielleicht eine Schleife erzeugt, die nicht mehr endet. Ist ein unfertiger Gedanke.

Gibt es noch andere Möglichkeiten?

**BugFix**

Ich würde den Vorgang in einer Logdatei (dafür bietet AutoIt einen eigenen Befehl) protokollieren. Wenn Fehler, auch (sofern das Skript das ermöglicht) die Ursache und Meldung an den User.

misterspeed

Grundsätzlich würde ich auch eher die Backupdateien prüfen. Das sollte dein Script aber ohnehin tun, denn wenn eine Backupdatei warum auch immer nicht erstellt werden kann solltest du davon zeitnah Kenntnis erhalten, damit das Problem behoben werden kann und nicht monatelang unentdeckt bleibt. Eine Warn-/Fehlermeldung sollte den Anwender hier informieren.

Aber natürlich hast du recht, dass die mehrmalige Scriptausführung im Fehlerfall dann evtl. nicht mehr sauber unterbunden wird. Daher ist eine zusätzliche Logdatei sinnvoll. Hier würde ich dann nicht nur die Ausführung ansich protokollieren, sondern auch den Erfolg/Misserfolg, rein informativ die Dauer und alle "gewollten" Abbrüche der Ausführung. Ob Abbruch oder nicht kannst du einfach durch das Änderungsdatum der Logdatei entscheiden.

Rechtetechnisch solltest du beim Schreiben von (Log-)Dateien vielleicht noch beachten, dass Windows Standardverzeichnisse in der Regel von der Benutzerkontensteuerung und evtl. Antivirensoftware geschützt werden. Deine Log Datei sollte also nicht unbedingt unter "C:\programme\.." liegen. Ich empfehle die Logdatei im Zielverzeichnis der Backups abzulegen, da du hier ohnehin Schreibrechte sicherstellen musst.

Du solltest die Rückgabewerte der Log Schreibfunktion prüfen und so schon vor Beginn des Backups bei Schreibproblemen der Logdatei eine Warnung und einen Programmabbruch auslösen.

Professor Bernd

Hallo Leute, so macht das Spaß!

Vielen Dank für eure Anregungen! Dadurch habe ich mich entschieden, die Prüfung per Log-Datei durchzuführen (_FileWriteLog).

Beim Speicherort der Log-Datei habe ich mich für das Script-Verzeichnis entschieden, das im Laufwerk D liegt. Dort sollten Schreibrechte mit den geringsten Störfaktoren vorhanden sein.

Vielen Dank an euch! Soweit ist das Problem gelöst.

Hintergrund-Details für Leseratten :)

Bei mir hat ein Umzug von einen alten PC auf einen neueren PC stattgefunden und gleich von Win XP auf Win 10. Auf XP lief ein Script das auf Win 10 übertragen werden soll. Warum dann nicht auch gleich alte Fehler beseitigen?

Beim alten Scirpt gab es auch schon eine Log-Funktion, die ich selbst geschrieben habe. Das Log enthielt pro Ausführung "Start", "Ende" und "Dauer". Geprüft wurde aber nicht die Log-Datei, die war nur informativ (z. B. um zu sehen, wann ich meinen Desktop mal wieder entrümpeln musste). Heute gibt es "_FileWriteLog" (danke BugFix) was meine Log-Funktion überflüssig, und das neue Script übersichtlicher macht.

Das Speichern der Log-Datei im Zielverzeichnis ist an sich eine gute Idee. Warum ich mich dagegen entschieden habe, hat folgenden Grund. Wenn in der Vergangenheit Fehler aufgetreten sind, war es meistens weil Windows die Laufwerks-Buchstaben mal wieder durcheinander gebracht hat. Somit war das Zielverzeichnis nicht erreichbar. Im Alltag sah es dann so aus, dass mitten in einer anderen Tätigkeit eine Fehlermeldung kam (z. B. beim E-Mail Schreiben), die ich erst mal schnell wegklickte und mich erst später darum kümmerte. Bei einem nicht erreichbaren LW würde natürlich auch keine Log-Datei geschrieben und es könnte nichts nachgesehen werden.

Ihr habt auch eine erweiterte Protokollierung vorgeschlagen, was ich sehr interessant finde!

- Erfolg/Misserfolg

- alle "gewollten" Abbrüche der Ausführung

- Fehler-Ursache

- Meldung an User

- Backupdateien prüfen (wurde erstellt, evtl. Archiv prüfen -> zeitaufwendig?)

Zitat von misterspeed

Du solltest die Rückgabewerte der Log Schreibfunktion prüfen und so schon vor Beginn des Backups bei Schreibproblemen der Logdatei eine Warnung und einen Programmabbruch auslösen.

Auch ein interessanter Gedanke. Geplant war eigentlich, nur am Ende der Ausführung einen Log-Eintrag zu erstellen. Aber vielleicht baue ich zusätzlich eine Schreib-Prüfung ein, vor der Ausführung der Backup-Sets. Mal sehen.

Summa summarum ist vieles davon natürlich ein wenig übertrieben, vor allem weil es seit Jahren keine größeren Probleme gab. Aber wenn ich schonmal dabei bin, warum nicht!? Have Fun!