Zitat von myrtille

Never copy&paste!

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!

Hier fehlen Prozentzeichen (alles im ftp1, jeweils beim %system,drive%):

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.

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

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

rfsize=%%m
lfsize=%%m

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

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

multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Microsoft Windows XP Professional - abgesicherter Modus" /noexecute=optin /fastdetect /safeboot:minimal
         

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

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

Zitat von ordell1234

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

-> Besserung brachte, wie bei ftp2 lfsize auf ne von rfsize verschiedene Variable, sprich %%k, zu setzen.

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.

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

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

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.

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.

Gleicher Effekt bei Verwendung der mexe.com?

Yep, zumindest bei mir. Kann man nicht einfach das TempDir der EUpdate.ini auf %temp% (C:\escan) legen? Gruß, ordell

Zitat von ordell1234

Kann man nicht einfach das TempDir der EUpdate.ini auf %temp% (C:\escan) legen?

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

Auszug aus der Eupdate.ini:
...
DestDir=C:\eScan
TempDir=C:\eScan\FtpTemp
...

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

:files

TempDir=%temp%\FtpTemp >> %temp%\EUpdate.ini
         

Zitat von ordell1234

Steh ich aufm Schlauch ...

Ach, so lang ist der doch niemals SCNR

...oder bastelst du die EUpdate.ini nicht selbst?!

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.

Zitat von MightyMarc

Ach, so lang ist der doch niemals SCNR

Muss er auch nicht, ich hab kurze Beine.

Zitat von MightyMarc

Ich schätze mal, die download.exe trägt ihren namen zu recht und macht nichts anderes.

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.

Zitat von ordell1234

Hmm, naja, so richtig schlau werde ich daraus nicht.

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ß

Zitat von ordell1234

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.

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)

Zitat von MightyMarc

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

Genau das macht doch die ftpfind.bat:

echo SourceURL=http://update6.mwti.net/pub/update >> %temp%\EUpdate.ini
echo HTTPHost=http://update6.mwti.net/sendinfo >> %temp%\EUpdate.ini

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

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

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

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)