icsat
Goto Top

Zwei Dateien vergleichen (z.B. auf Größe) nach erfolgtem Copy

Zum Ausführungszeitpunkt des Copy Komandos kann ich nicht sicher sein, dass die Quelldatei bereits vollständig vorhanden ist, wie kann ich prüfen ob die Quelldatei sich nach dem Copy noch verändert hat?

Hallo,

ich bekomme mehrere Dateien auf einem Server mittels openFT zur Verfügung gestellt und mit der zuletzt gesendete Datei wird ein Verarbeitungsscript angestoßen. Im Verarbeitungsscript werden die Dateien mittels copy an einen anderen Ort kopiert.

Nun hat sich in der Praxis herausgestellt, dass eine Datei gelegentlich noch nicht vollständig vorhande ist, wenn der Copy anläuft und somit nur zum Teil (wenn auch zum größten) kopiert wird. Grund dafür ist die Tatsache, dass die "Problemdatei" mit ca. 1GB deutlich größer ist als die letzte Datei mit 2kb und der openFT wohl nicht so sauber läuft, dass die letzte Datei erst gesendet wird wenn die anderen bereits vollständig übertragen wurden.

Da ich an den vorgelagerten Abläufen (Jobs / openFT / etc.) erst einmal nichts ändern möchte bzw. nur mit erheblich Aufwand etwas ändern kann würde ich gerne wissen ob jemand eine Möglichkeit kennt nach dem Copy die Dateien ohne große Schwierigkeiten zu vergleichen.

Ein Vergleich der Dateigröße würde meiner Meinung nach vollkommen ausreichen, der Inhalt müßte nicht geprüft werden.

Ich bin mir nicht sicher, ob dieses einfach mit dem Schalter /v erreicht werden kann, denn der Copy ist zu dem betroffen Zeitpunkt ja ohne Fehler und vollständig gelaufen (ERRORLEVEL =0), hat hierzu jemand Erfahrungen?

Oder besteht die Möglichkeit einen exclusiven Copy durchzuführen? Der müste doch fehlschlagen, da noch in die Quelldatei geschrieben wird?

Mit freundlichen Grüßen

André

Content-ID: 24649

Url: https://administrator.de/contentid/24649

Ausgedruckt am: 22.11.2024 um 05:11 Uhr

stagatto
stagatto 27.01.2006 um 13:43:06 Uhr
Goto Top
Um zwei Dateien zu vergleichen fällt mir spontan das Unix-Tool diff ein.

Damit können Text- und Binärdateien verglichen werden, bei einer Textdatei werden die Unterschiede ausgegeben, bei einer Binärdatei lediglich ob unterschiede bestehen.

Für Windows stellt cygwin eine entsprechende Toolsammlung parat. Habe aber leider keinen aktuellen Downloadlink.

stagatto
derCaptain
derCaptain 27.01.2006 um 13:45:29 Uhr
Goto Top
Ich denke, das hier dürfte dir weiterhelfen:
stagatto
stagatto 27.01.2006 um 13:48:45 Uhr
Goto Top
... hab den Link gefunden und unter Links hinzugefügt:

http://unxutils.sourceforge.net/

stagatto
icsat
icsat 27.01.2006 um 15:19:57 Uhr
Goto Top
Danke, ich würde jedoch am liebsten ohne zusätzliche Tools auskommen.
icsat
icsat 27.01.2006 um 15:55:05 Uhr
Goto Top
Danke,

eigentlich war der Tip ganz gut.
Die Bewertung hatte ich leider schon abgegeben nachdem ich es auf meinem Windows NT Client probiert habe und es nicht funktioniert hat, da der FOR dort kein %%~zI unterstützt. Auf dem 2003 Server scheint dieses jedoch der Fall zu sein, ich bekomme aber trotzdem kein Ergebnis, denn %%~zI scheint leer zu sein.
Hast Du da eine Idee?
icsat
icsat 27.01.2006 um 17:17:21 Uhr
Goto Top
Hallo derCaptain,

noch mal Danke für Deinen Tip.

Wer lesen kann ist klar im Vorteil! Nachdem ich die Anführungszeichen in der Klammer weggenommen habe hat es auch mit der Ausgabe funktioniert. Das Problem mit der Lösung mittels "for /R %PATH% ..." ist jedoch die Tatsache, dass ab %PATH% in dem angegebenen Verzeichnis und allen unterverzeichnissen nach der Datei gesucht wird, es also zu vielen Ergebnissen kommt wobei nur das erste Ergebnis einen brauchbaren Wert hat.

Dennoch hat Dein Tip mich auf meine Problemlösung gebracht:
for /D %%I in ("%DATEI1%") do for /D %%J in ("%DATEI2%") do if %%~zI == %%~zJ echo Die Dateien sind gleich groß! > %LOG%
for /D %%I in ("%DATEI1%") do for /D %%J in ("%DATEI2%") do if not %%~zI == %%~zJ echo Die Dateien sind nicht gleich groß! > %LOG%

MfG André
Biber
Biber 27.01.2006 um 19:03:14 Uhr
Goto Top
Moin icsat,

nur als Fußnote dazu:
a) Du kannst lange Zeilen im Batch "dokumentiert" oder "undokumentiert" trennen:

"dokumentiert" durch "Klammerung" nach dem "...DO":
for /D %%I in ("%DATEI1%") do (
for /D %%J in ("%DATEI2%") do (
if %%~zI == %%~zJ echo Die Dateien sind gleich groß! > %LOG%
))

"undokumentiert": durch Eingabe von Caret ("^") und RETURN direkt dahinter. An beliebiger (Leer-) Stelle.

b) Etwas sinnvoller wird das LogFile, wenn Du den Dateinamen mit in die LogZeile schreibst.
Und mit ">>" das Logfile weiter- statt mit ">" überschreibst face-wink
... echo Die Dateien %%~nI sind nicht gleich groß! >> %LOG%

HTH Biber
icsat
icsat 28.01.2006 um 13:13:47 Uhr
Goto Top
Hallo Biber,

zu a)
ist mir bekannt, ist wirklich 'ne hübsche Sache und meines Wissens durch MS nicht wirklich dokumentiert.

zu b)
die beiden Zeilen sollten nur zeigen, wie ich den Vergleich gelöst habe. Es ist mir schon klar, dass es wenig Sinn macht ein Log-Datei mit jedem Eintrag neu anzulegen face-wink

Gruß André
Biber
Biber 28.01.2006 um 13:27:22 Uhr
Goto Top
Moin André,

zu b) die beiden Zeilen sollten nur zeigen, wie ich den Vergleich gelöst habe.
Es ist mir schon klar, dass es wenig Sinn macht ein Log-Datei mit jedem Eintrag neu anzulegen

face-big-smile
...ich habe auch gestern lange überlegt, ob ich Punkt b) dazuschreibe... dachte mir schon, dass das nur ein Beispiel sein sollte.
Der Hinweis war mehr gedacht für nachfolgende Mitleser.

Also bitte nicht als persönlich gemeinte Unterstellung auffassen - war nicht so gemeint. face-wink

Schönes Wochenende
Frank / der Biber aus Bremen
22736
22736 01.02.2006 um 00:52:24 Uhr
Goto Top
Hallo André,

vielleicht ist Robocopys Monitor-Funktion etwas für Dich. Es gibt zwei Parameter:

/MON:n = MONitor source; run again when more than n changes seen.
/MOT:m = MOnitor source; run again in m minutes Time, if changed.

Viele Grüße
Peter
icsat
icsat 01.02.2006 um 06:53:11 Uhr
Goto Top
Hallo Peter,

Robocopy habe ich auch schon gesehen, mich aber nicht weiter damit befasst.
Die o.g. Lösung funktioniert für meine Zwecke hoffentlich ausreichend.

Zu der Robocopy Lösung würde mich interessieren
a) läuft ein Script hinter dem Befehl weiter und der Copy wird unabhängig vom Script wiederholt oder steht das Script m Minuten?
b) würde der Robocopy nach dem zweiten mal erneut nach m Minuten auf Veränderungen prüfen?

Gruß André
icsat
icsat 02.02.2007 um 19:03:07 Uhr
Goto Top
Hallo,

die oben angegebene Lösung funktioniert von der Sache her sehr gut hat mein eigentliche Problem aber nicht gelöst, da der Fehler weiterhin aufgetreten ist.

Falls es jemanden interessiert:
Die Ursache lag in einem Fehler im openFT Job. Die Dateien die Übertragen werden setzen alle ein Flag sobald sie vollständig übertragen wurden und die letzte Datei, die auch das Verarbeitungsscript startet wird erst übertragen wenn all Flags gesetzt sind. Leider war das Flag für die "Problemdatei" immer gesetzt, so dass die Verarbeitung auch gestartet wurde wenn Datei noch gar nicht übertragen war.

Ich werde die Frage mal als gelöst kennzeichen.