Ja ne, ist klar, Katrin. Ich mach die 58 Einträge von Hand ;)
Die Devise müsste eher lauten: wenn Du etwas änderst, dann speicher auch ab!

OK, die Variable ist jetzt wieder eine richtige Variable, Danke.

http://www.file-upload.net/download-313291/findftp.bat.html

Gruß

Marc

Mit h bitte, wenn schon denn schon. :p

Fileupload scheint down zu sein.
Kann das jemand bestätigen? Oder bin ich die einzige die ne Fehlermeldung bekommt, wenn sie versucht die batch runterzuladen?

lg myrtille

EDIT: Hat geklappt und läuft durch. Hab daher das Fehlerfangen nicht näher betrachtet. ;)

So Freunde der Nacht und insbesondere Kathrinchen,

ein paar Auffälligkeiten habe ich von der vorletzten findftp.bat (fileuploadlink 313191) zu melden, die aktuelle habe ich mir nicht angeschaut.

Ich verstehe es aber nicht durchweg, da ich weder den komischen for-Befehl kapiere, noch verstehe, was ein "token" ist. Naja, im nächsten Leben... :heulen:

:ftp1
Im abgesicherten Modus läuft die batch bei mir nicht durch, wenn ich ftp1-Server wähle. In diesem Fall wird die %lfsize% nicht angelegt. Mag das der Grund sein?
-> Besserung brachte, wie bei ftp2 lfsize auf ne von rfsize verschiedene Variable, sprich %%k, zu setzen.

:nodl
Hier müßte nach meinem Verständnis 'ndl' gesetzt werden und nicht 'srv' -> die Batch steigt aus, da %ndl% nicht mehr existiert

Des weiteren sollten noch die Updates von FtpTemp nach escan kopiert werden. Zumindest blickt escan das bei dem Aufruf der mwavscan.exe nicht und scannt mit alten Sigs. Oder hast du (@Marc) einen speziellen Aufruf von escan vorgesehen, wo die Updates mit verwurstet werden? Dann bitte diese Anmerkung knüllen.

So das wars erst mal, irgendwie seh ich langsam den Baum vor lauter Wäldern nicht mehr. :crazy:

Ein error.log hab ich mal drangehangen, vllt hilfts weiter.


Zur boot.ini: Per batch an der Boot.ini rumzuschrauben halte ich ehrlich gesagt bei kompromittierten Kisten für ne Operation am offenen Herzen. Wie man über Kommandozeile im abgesicherten Modus neustartet, ohne die boot.ini zu verändern weiß ich nicht, Google hat mir nicht weiter geholfen. Andererseits macht msconfig ja auch nichts anderes als das "safeboot minimal" dranzuhängen. Was haltet ihr davon, der Boot.ini ne zweite Zeile hinzuzufügen und entsprechend Marcs Vorschlag das timeout auf 30 zu setzen?

Abschließend: MWAV downloaden und updaten würde ich im normalen Modus (bei Router auch abgesicherter Modus mögl), scannen komplett im abgesicherten Modus ohne Netzwerktreiber, Auswerten im Normalen Modus. Da können die TOs gleich das aufpoppende log posten. Sollte aber letztlich Geschmackssache sein.

Grüße und Guts Nächtle :party:

Öhm... beim Fernsehen kommt man ja auf die blödesten Ideen, aber wie sieht's eigentlich mit einer Vorabprüfung des OS aus?

Da haben wir doch schon die Tokens ;) Jedes einzelne durch Tabs oder Leerzeichen voneinander getrennte Element ist ein Token. Bei dem dir-Befehl auf dem FTP-Server ist der gesuchte Token der 5.
%%m kommt deswegen raus weil (man schaue sich die for-Schleife nochmal an) %%i als erster Token definiert ist (for %%a-z in definiert die Bezeichnung des ersten Tokens).
Beim dir-Befehl im Verzeichnis liegt die Größenangabe aber im 3. Token, deswegen %%k.
Da ich erstmal einen Server zum laufen bringen wollte, habe ich vermutlich vergessen, das bei ftp1 noch zu ändern.

Bereits geändert, nur noch nicht veröffentlicht.

Gleicher Effekt bei Verwendung der mexe.com?


Zum Safeboot will ich grad nicht zuviel sagen, aber ein timeout wird das höchste der Gefühle sein.

Gruß

Marc

Ahh, bei der Token-Geschichte hat's endlich klick gemacht! Merci.Yep, zumindest bei mir. Kann man nicht einfach das TempDir der EUpdate.ini auf %temp% (C:\escan) legen? Gruß, ordell

"Nichts leichter als das", sprach Piggeldy...., nur eigentlich sollten die Dateien in %systemdrive%\eScan landen. Tun sie bei mir aber auch nicht :confused:

Steh ich aufm Schlauch und kriege gleich mordsmäßig eine gewinkt :kloppen:, oder bastelst du die EUpdate.ini nicht selbst?! :confused:

:files

Ach, so lang ist der doch niemals :D SCNR

Doch, genau das mache ich. Ich hatte aber gewisse Teile von einer Standard-Datei übernommen und laut derer ist das temporäre Downloadverzeichnis FtpTemp in %temp%. Nun sind wir aber Herr der Lage und können das einfach ändern.
Ich schätze mal, die download.exe trägt ihren namen zu recht und macht nichts anderes.

Muss er auch nicht, ich hab kurze Beine. :blabla:

Hmm, naja, so richtig schlau werde ich daraus nicht. Rufe ich mwavscan.exe/mexe.exe auf und aktualisiere über GUI, wird die EUpdate.ini geändert. Deine nette Serverreihenfolge scheint so zu bleiben, was das wichtigste ist, aber das Verzeichnis \ftptemp wird wieder angelegt. :balla:

Es wird noch deutlich konfuser ;)
Im FtpTemp-Ordner sollte sich eigentlich gar nichts befinden, wenn man ein http-Update macht. Und die Daten aus dem FtpTemp-Ordner werden wohl auch nicht übernommen, sonst wäre die schöne httpsite.txt nämlich futsch.
Alles klar?

Ich frag mich gerade, ob die httpsite.txt überhaupt funktionale Bedeutung hat. Die schöne httpsite.txt wird sowieso mit erfolgreichem Aufruf der download.exe durch die hässliche httpsite.txt ersetzt, da sie Bestandteil des Updates ist.

Gebe ich der EUpdate.ini eine unsinnige sourceurl, bricht der Download laut download.log erfolglos ab, alternative http-Server sucht die faule Kiste nicht. Daher spielt wohl auch die Reihenfolge der Server in httpsite keine Rolle, sprich auf Schönheit kommt es nicht an.

Denke mal eher, die httpsite.txt ist nur Hilfe zur Selbsthilfe des Users, dass der sich auch mal was manuell laden kann, sollten die Server dicht sein. Gruß

Ja, nein, weiß nicht. Wie ich einige Seiten zuvor erwähnte soll die httpsite.txt wohl eine Art Serverliste darstellen. Das sie nicht funktionierte führte zur geänderten httpsite.txt. Der erste Server in der geänderten Fassung wurde bei ja tatsächlich in die EUpdate.ini übernommen. Es wäre also einen Versuch wert, die httpsite.txt mit einem Schreibschutz zu versehen. Im Grunde genommen ist das aber auch grad egal, da der Anwendungsfall hier im Forum eigentlich nur ein Update vorsieht und das funktioniert ja auch (mit entsprechenden Parametern in der EUpdate.ini).
Aber vllt bekommt man dieses grundsätzlich Problem noch gelöst (z.B. eScan über eine Batch starten, die erst den richtigen Server in die EUpdate.ini einträgt und dann erst eScan startet).

Gruß

Marc

Edit:
Schreibschutz auf der httpsite.txt scheint zu genügen.

Edit2:
Ich zweifle doch stark an dem Vermögen der eScan-Entwickler. eScan zeigt mir ein aktuelles Definitionendatum an, in den Logs findet sich aber ausschliesslich ein einziges Datum (das erste) :confused:

:confused: Genau das macht doch die ftpfind.bat:Dieser Eintrag entscheidet imho, welcher Server angesprochen wird, und dieser Eintrag bleibt glücklicherweise, wie er ist. Um die httpsite.txt schert sich die EUpdate.ini meines Erachtens nicht, übernimmt also auch nichts von ihr. Müll erzählt? Gruß Frank

Edit: Ich habe probiert, httpsite.txt an erster Stelle server 5 zu setzen, die Zuweisung an die Eupdate.ini auf Server 3. In jedem Download.log aussschließlich Server 3, bei nicht erreichbaren Servern findet null Download statt.

Ach, weiss der Geier! Ich verlier hier langsam den Überblick :crazy:

Mit

download.exe
copy %systemdrive%\eScan\FtpTemp\*.* %systemdrive%\eScan

bekomme ich auch das richtige Definitionsdatum im Log angezeigt.
TempDir=C:\eScan hat das leider nicht geschafft :confused:

BTW mit Batch meinte ich eine Batch analog zu einer Verknüpfung..vllt meinte ich das...

Edit: na dann können wir die httpsite.txt ja begraben ...
Wieso die dann bei jedem Update neu angeschleppt wird :confused:

Edit2:
mir kommt gerade der Verdacht, dass
a) destdir von der Download.exe komplett ignoriert wird oder
b) die Spastologen tempdir und destdir vertauscht haben (aber dann sollte das Update aus eScan heraus auch nicht funktionieren)