Beiträge von misterspeed

Automatisch vermutlich eher nicht. Du könntest aber manuell eine Liste aller Funktionen erstellen und diese dann ausgeben. Alternativ kannst du natürlich auch den gesamten Quellcode in der EXE Datei Archivieren und zur Laufzeit per Regex die Funktionsnamen/-deklarationen im Script ermitteln.

Hier ein wenig Lektüre zum Speichern/Auslesen des Quellcodes:
Quelltext in der Exe-Datei archivieren

Wenn du die dort beschriebenen Maßnahmen etwas modifizierst kannst du Anstelle des ganzen Quellcodes natürlich auch nur eine Liste der Funktionsnamen im EXE Header hinterlegen.

EDIT:

Sehe gerade die Links im Beitrag von peethebee funktionieren nicht mehr, evtl. kann er sein Posting ja mal editieren.

So ist es FileOpen und FileClose braucht man nur unter bestimmten Umständen. Es ist z.B. sehr viel performanter wenn man die Datei nur einmalig öffnet und schließt wenn man tausende male in kurzer Zeit kleine Häppchen in die Datei schreibt, da hier dann der Schreibcache wirkt und unnötiges Öffnen/Schließen entfällt. Auch macht es Sinn FileOpen zu verwenden wenn man einen bestimmten Schreib- oder Lesemodus erzwingen möchte. In deinem Beispiel halte ich FileOpen aber für überflüssig.

Nun zum eigentlichen Problem:

Am FileOpen liegt die Dateisperre nun jedenfalls nicht mehr, zumindestens dann wenn das dein komplettes Script ist und du nicht noch irgendwo anderst die Datei "falsch" öffnest/schließt.
Die wahrscheinlichste Ursache ist also die FTP Funktion. Teste daher wie gesagt die aktuellen Funktionen aus der FTPex.au3 bzw. aktualisiere deine Autoit Version sofern diese extrem veraltet sein sollte.

Sofern noch nicht passiert wäre evtl. auch ein Rechnerneustart anzuraten. Vielleicht ist da ja nachwievor ein Dateihandle aus vorherigen Fehlversuchen geöffnet.

Zitat von autoBert

hat die Tests für offene Worddokumente bestanden. Bei in NotePad geöffneten Dateien versagt es aber auch.

Nun ohne es genau zu wissen könnte ich mir vorstellen, dass Notepad die Datei nicht sperrt bzw. geöffnet hält, sondern lediglich einmalig einliest und die Datei dann bis zum Speichervorgang geschlossen lässt. Eine Prüfung ob die Datei von einem Programm "geöffnet" ist und bearbeitet wird ist in solch einem Fall jedenfalls nicht möglich. Daher wäre es vielleicht noch interessant was genau der TE mit der Prüfung überhaupt sicherstellen möchte.

Neben den veralteten (oder nicht Standard) FTP Funktionen, welche du verwendest kommt grundsätzlich auch noch dein Virenscanner als Fehlerursache in Frage. Möglicherweise führt dieser eine Prüfung der Datei durch wenn diese per FTP ins Internet übetragen wird und verhindert so kurzfrisitg die erfolgreiche Löschung.

Lösung: Testweise Virenscanner deaktivieren und wenn erfolgreich zukünftig die Dateilöschung in einer Schleife durchführen bis diese erfolgreich ist (evtl. mit einem Timeout, damit dein Script nicht endlos erfolglos versucht die Datei zu löschen).

Nun da du nur noch in der Funktion _FtpPutFile() auf die später zu löschende Datei zugreifst liegt der Verdacht nahe, dass in dieser Funktion ein Dateihandle geöffnet aber nicht geschlossen wird. Ich frage mich woher diese Funktion stammt, denn die originale Autoit Funktion aus der FTPex UDF trägt den Namen _FTP_FilePut()

Dein Problem ist, dass du die Funktion FileOpen() bzw. FileWrite() und FileClose() falsch anwendest. Schau dir nochmal die Hilfe zu den Funktionen an.

FileOpen gibt dir ein Dateihandle zurück. Wenn du also FileOpen verwendest muss dieses Handle in allen weiteren FileWrites/Reads und letzlich im FileClose verwendet werden. Übergibt man an Filewrite hingegen einen Dateipfad ist ein vorheriges FileOpen wirkungslos oder führt evtl. sogar zum Zugriffsproblem, da im Falle eines FileWrites mit Dateipfad ein FileOpen innerhalb der Funktion durchgeführt wird, was aber dann scheitern dürfte wenn die Datei zuvor schon von dir exklusiv geöffnet wurde.

FileClose kann überhaupt nichts mit Dateipfaden anfangen und erwartet wie erwähnt ein Dateihandle.

Zitat von Schokolade

>>>du kannst aber auch für jeden Nutzer ein Verzeichnis anlegen auf dem nur er, das System und die Admistratoren alle nötigen Berechtigungen haben.
Das ist keine Option, denn a) zu aufwendig und b) zu unübersichtlich. Es soll schon so sein, dass in einem Verzeichnis alle Logfiles liegen, sodass man z.B. nach Datum sortieren kann, welches zuletzt geändert wurde.

Naja was heißt aufwendig? Die Ordner und Berechtigungsstruktur könnte man in Sekunden durch ein Script erstellen lassen. Für das Auswerten der Logs könnte man theoretisch auch eine Autoit GUI schreiben, die dir Rekursiv alle Logfiles auflistet und evtl. sogar noch deren Inhalt auswertet, Statistiken zu den von dir zu versteckenden Infos wie "User Aktivität" erstellt usw.

PS: Ich habe oben zum "ERSTELLER-BESITZER" Vorschlag vorhin noch etwas editiert falls du es übersehen hast...

Achja eine Idee hätte ich noch. Ändere die Datei-Berechtigungen im Ordner dahingehend, dass der "ERSTELLER-BESITZER" einer Datei zusätzlich Lese Rechte erhält. Dadurch dürften nur selbst erstelle Dateien lesbar sein.

EDIT:

Als Ergänzung könnte man auch das hier testen

• Ordner listbar für alle Benutzer, aber keine Dateilese Rechte (Option: Nur dieser Ordner)
• Dateien Erstellen für alle Benutzer (Option: Nur dieser Ordner)
• Dateien nur für "ERSTELLER-BESITZER" lesend und schreibende Rechte (Nur Dateien)

Ob das so den gewünschten Effekt hat müsste man testen, hab ich jetzt aber keine Lust dazu. Der Nachteil der Listrechte wäre aber, dass man prinzipiell eine Liste aller Benutzer einsehen kann und außerdem anhand der Datei Änderungsdaten evtl. Rückschlüsse auf die Anwesenheit und Ab- und Anmeldezeiten der Benutzer schließen kann. Was ja laut deiner Aussage verhindert werden muss.

Zitat von Schokolade

PS: Das mit dem Logserver scheint mir mit Kanonen auf Spatzen zu schießen.

Das kommt natürlich auf eure Infrastruktur an. Aber in mittleren bis großen Unternehmen ist es üblich, dass bereits ein solcher zentraler Server vorhanden ist, welcher sämtliche Logfiles im Unternehmen entgegennimmt. Seien es Logs von diversem Hardware Equipment wie Switche, Firewalls, Accesspoints bis hin zu Serverlogs und evtl. sogar Clientlogs. Die dort angesammelten Logs können dann wunderbar "live" durch spezialisierte Software durchsucht und automatisch auf Ungregelmässigkeiten analysiert werden. Für eine 10 Mann Firma ist sowas aber natürlich etwas übertrieben.

Was dein Batch Script anderst macht kann man dir hier nicht sagen. Du hast weder ein funktionierendes Beispiel Batch Script bereitgestellt noch Details dazu gepostet wie und in welchem Benutzer Kontext die Batch- und Autoit Scripte ausgeführt werden (Systemuser, Als Administrator, ohne/mit #requireadmin,...). Auch hast du keine Angaben zu den involvierten Betriebssytem- und Autoit Versionen gemacht. Evtl. ebenfalls relevant wären Angaben dazu ob die Benutzer lokale Administratoren sind, ob die Windows Benutzerkontensteuerung aktiv ist und welche lokale Antivirensoftware eingesetzt wird.

Prinzipiell könntest du den Teil des Logversandes/-schreiben testweise als Batch / CMD Aufruf in deinem Autoit Script einbauen und schauen ob es dann wieder funktioniert.

Wenn er das macht kann aber jeder alle Logs lesen. Das einzige was man dazu braucht ist der komplette Netzwerkpfad zur Datei. Den Ordner nur vor Auflistung zu schützen schützt noch lange nicht die Dateien darin. Da die Logfiles mit Sicherheit nach einem fixen Schema benannt sind dürfte es nicht all zu schwer sein auf den Namen von fremden Logfiles zu schließen.

Die vom TE angewendete Methode halte ich daher für problematisch, zumindestens in Verbindung mit deiner vorgeschlagenen Rechteanpassung.

Ich würde daher wie auf deinem Screenshot zu sehen ist einen nicht personalisierten Systemuser für die Datenübertragung auf das Netzlaufwerk nutzen. Nur dieser Systemuser hat ausreichende Rechte um die Logfiles zu bearbeiten. Die eigentlichen User Scripte schreiben ihr Logfile nur auf die lokale Festplatte und diese werden dann von einem weiteren Script welches im Kontext des Systemusers ausgeführt wird letzlich auf das Netzlaufwerk kopiert (in Intervallen oder bei jeder Dateiänderung des lokalen Logfiles). Alternativ könnte man die Logfiles auch durch ein Script welches auf dem Dateiserver läuft regelmässig von den Clients abholen (Administrative C$ Freigabe auf dem Client Rechner).

Letztere Variante hätte zumindestens den Vorteil, dass keine Accountdaten für den Systemuser auf dem Client gespeichert werden müssen. Wenn man die Aufgabenplannung nutzt um das Übertragungsscript zu starten dürfte das gespeicherte Passwort des Systemusers aber auch im ersteren Fall vor dem Anwender sicher sein.

Weitere Alternative wäre es ganz auf Dateibasiertes Logging zu verzichten und Stattdessen die Logs "live" per TCP/UDP an einen evtl. bereits vorhandenen Logserver zu übertragen.
Stichwort syslog --> https://de.wikipedia.org/wiki/Syslog
Du findest hierfür evtl. sogar passende Client Implementierungen in Autoit.

Zitat von Bioshade

Zum Thema:

Wir haben einen Webspace gemietet (7,00 € pro Monat insgesamt), dort Mail-Adressen eingerichtet und innerhalb von vielleicht einer Stunde eine eigene API erstellt, mit der eine Mail an alle versendet werden kann. Auf den Mobilgeräten ist für das neue Postfach die Push-Benachrichtigung aktiviert und schon .... hat man den gleichen Effekt wie bei Pushover für deutlich weniger Geld mit deutlich mehr Möglichkeiten. Vielleicht ist das auch für unseren Stoani eine Option (vor allem, wenn er bereits einen Webspace hat).

Dachte schon ich bin hier der einzige der alt genug ist um die gute alte Email noch zu kennen. Genau das wäre auch mein Vorschlag. Man braucht dafür ja noch nichtmal einen eigenen Email Server oder Webspace, sondern es reicht schon wenn man sich eine zentrale Emailadresse bei einem beliebigen Anbieter zulegt und alle Nutzer deines Benchrichtigungsdienstes melden sich für den Dienst mit ihrer präferierten eigenen Email Adresse an oder ab indem sie eine Nachricht an deine Email schicken (vergleiche das Prinzip einer Mailingliste). Alternativ kannst du die Empfängerliste natürlich auch selbst pflegen.

Anstatt einem herkömmlichen Email Programm verwendest du dann deine Autoit Anwendung um Emails an die angemeldeten Benutzer zu schicken. Dafür gibt es jedemenge fertige Funktionen (Suchbegriffe: Autoit / SMTP / POP).

Zitat von autoBert

Edit: Gibt mit Sicherheit einen Betriebssytem-Befehl der die öffentliche Adresse liefert.

Jupp nslookup z.B.

nslookup myip.opendns.com resolver1.opendns.com

EDIT:

Achja für AutoMit...
Vorgehensweise: Google -> "windows cmd get public ip" -> 1. Treffer -> einer der ersten Beiträge ganz oben
Zeitaufwand: ca. 30 Sekunden

Und wo ist hier das Problem? Wenn du Clients identifizieren willst dann arbeite mit einem "Lizenzserver". Jeder berechtigte Client bekommt von dir eine Lizenzdatei (oder eben nur einen Lizenzschlüssel) und muss diesen bei jeder Programmnutzung zunächst an den Server übermitteln. Wenn der Server den Schlüssel nicht kennt oder dieser nicht mehr gültig ist, dann sagt er dem Client, dass er Pech hat und sich meinetwegen selbst löschen soll. Anstatt jedem seine eigene EXE zu geben musst du nur jedem einen Schlüssel in die Hand drücken, welchen du jederzeit am Server zurückziehen/sperren kannst.

EDIT:

Um die Weitergabe eines gültigen Schlüssels zu verhindern kannst du diesen individuell an die Hardware/Software des berechtigten Client PCs koppeln (z.B. die MAC Adresse der Netzwerkkarte, den Windows Key, Windows HardwareID oder sonstige eindeutige Merkmale). Beispiele zu mehr oder weniger durchdachten Lizenzserver Scripten findest du hier und im englischen Forum sicher einige.

Jenachdem was erreicht werden soll wären vielleicht auch noch diese Funktionen eine Variante

SplashTextOn(...)
SplashImageOn(...)
SplashOff()

Eine wirklich befriedigende Lösung wirst du aber wohl nur durch eine individuelle GUI erreichen.

Genau. So wirklich verstanden habe ich auch nicht was du eigentlich erreichen bzw. im Script dynamisch ersetzen möchtest. Wenn du sowas schon machen willst/musst arbeite mit eindeutigen Strings im Template, welche vom Compilerscript ausgetauscht werden, so wie Kanashius das beschrieben hat. Dabei muss man aber vorsichtig sein. Deine Platzhalterstrings müssen wirklich eindeutig sein und dürfen nicht mit anderen Scriptbestandteilen identisch sein. Die Frage bleibt aber warum du das überhaupt tun musst/willst. Es wäre doch viel praktischer wenn deine Exe nur einmal kompiliert werden müsste und trotzdem individualisiert wäre. Je nach Aufgabe kann man das sicher sehr viel geschickter realisieren. Nebenbei gäbe es noch die Möglichkeit deine Individualisierung im Exe-Dateiheader zu verstecken und diesen im Hauptcompilat durch Bearbeiten der EXE auf Binärebene zu ändern. Das Script müsste diese Versteckte Information dann aber ebenso zur Laufzeit aus der eigenen Binärdatei auslesen.

Hier mal ein simples Beispiel zur Nutzung der winhttp.au3

https://www.youtube.com/watch?v=uu1oTpmMgsk

In deinem Fall wirst du sehr wahrscheinlich erstmal einen Login machen müssen wie dort gezeigt und anschließend vermutlich ein oder mehrere GET Paket(e) mit der Downloadseite und letztlich Download URL an den Webserver senden müssen.

Dazu brauchst du wie im Video zu sehen ist erstmal einen Browser mit einem passenden Plugin um die Pakete mitzuschneiden bzw. zu analysieren. Hier wird Firefox mit dem Plugin Live HTTP Headers verwendet. Wesentlich einfacher und übersichtlicher wird der Mitschnitt im Übrigen wenn du während deiner Analyse nur einen Tab mit der Zielwebseite geöffnet hast.

Das schaut vielleicht auf Anhieb etwas komplizierter aus, aber wenn du das ein paar mal gemacht hast wirst du die notwendigen Informationen recht schnell ermitteln können.

Naja anstatt stringformat zu nutzen könntest du den SQL-String ja auch dynamisch in einer Schleife zusammenbauen lassen. Die Spaltennamen könntest du z.B. zunächst aus der DB auslesen und dann in einen passenden String zusammenbauen. Deine Values hast du ja offenbar schon in einem Array vorliegen, auch hier wäre es dann ein leichtes daraus einen Komma getrennten String zu generieren.

Aus deinem kompliziereten SQL Statement

insert into hit6result (h6rracetime,h6rracenumber,h6rracenumberix,h6rball01,h6rball02,h6rball03,h6rball04,h6rball05,h6rball06,h6rball07,h6rball08,h6rball09,h6rball10,h6rball11,h6rball12,h6rball13,h6rball14,h6rball15,h6rball16,h6rball17,h6rball18,h6rball19,h6rball20,h6rball21,h6rball22,h6rball23,h6rball24,h6rball25,h6rball26,h6rball27,h6rball28,h6rball29,h6rball30,h6rball31,h6rball32,h6rball33,h6rball34,h6rball35,h6rprize06,h6rprize07,h6rprize08,h6rprize09,h6rprize10,h6rprize11,h6rprize12,h6rprize13,h6rprize14,h6rprize15,h6rprize16,h6rprize17,h6rprize18,h6rprize19,h6rprize20,h6rprize21,h6rprize22,h6rprize23,h6rprize24,h6rprize25,h6rprize26,h6rprize27,h6rprize28,h6rprize29,h6rprize30,h6rprize31,h6rprize32,h6rprize33,h6rprize34,h6rprize35,trans_flag,last_access) VALUES ($var2[35] ........ where=" & $MAXH6RACENUMBERIX[0]

wird dann etwas sehr viel übersichtlicheres

$sColumns = "h6rracetime,h6rracenumber,...,last_access" ; fragst du vorher aus der DB ab und baust dir dann deinen String zusammen
$sValues = "???" ; bekommst du von irgendeiner Webseite und speicherst das gleich als formatierten String oder baust dir den String aus deinem Array...


$sSQL ="insert into hit6result (" & $sColumns & ") VALUES (" & $sValues & ") where=" & $MAXH6RACENUMBERIX[0]

Hier ein Beispiel wie du den Value String aus dem Array bauen kannst:

dim $sValues = ""


for $i = 0 to ubound($Var2)-1
   $sValues &= $Var2[$i] & ","
next


$sValues = stringtrimright($sValues,....) ; letztes Komma entfernen... siehe Hilfe

Würde dir empfehlen das ganze mit der winhttp.au3 zu lösen. Hier kannst du vom Login bis zum Download alles realisieren.
Ist auch wesentlich performanter, da du direkt mit dem Webserver kommunizierst und nicht erst einen aufgeblasenen Browser laden musst, der sämtliche Scripte, Grafiken und Werbebanner vollständig lädt. Mit WinHTTP bekommst du direkt den Quellcode der Webseite und entscheidest selbst welche Inhalte du laden oder interpretieren willst.

Das hier ist ein Programmierforum. Ich sehe absolut keinen Zusammenhang zwischen Programmiersprachen und TV / Fussball Streams. Vielleicht solltest du lernen richtig zu googlen und deine Frage in einem passenderen Forum posten.

Zitat von AutoMit

zu (1)
wenn es einen Weg gibt, das mit der Forensuche zu tun, ist mir das lieber, vielleicht kennt jemand eine Lösung für die Forensuche (nicht Google, sonst hätte ich nach Google gefragt )
Vielleicht erbarmt sich der Forenbetreiber und setzt die Mindestanzahl auf drei Zeichen, damit man im Titel auch Sachen findet wie UDF, gui etc.).

Darauf wirst du lange warten können. Es hat einen Grund warum man die Mindestanzahl an Zeichen höher angesetzt hat. Je niedriger die Zeichenanzahl, desto umfangreicher wird die Ergebnismenge und somit die Last der Datenbankabfrage. Das könnte man z.B. für eine DOS Attacke ausnutzen. Wenn man google richtig nutzt kann man problemlos jeden relevanten Beitrag hier im Forum finden. Aber google magst du ja scheinbar nicht... warum auch immer.