12
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é
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é
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 24649
Url: https://administrator.de/forum/zwei-dateien-vergleichen-z-b-auf-groesse-nach-erfolgtem-copy-24649.html
Ausgedruckt am: 22.12.2024 um 22:12 Uhr
12 Kommentare
Neuester Kommentar
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
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
Ich denke, das hier dürfte dir weiterhelfen:
Danke, ich würde jedoch am liebsten ohne zusätzliche Tools auskommen.
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?
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?
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é
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é
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
... echo Die Dateien %%~nI sind nicht gleich groß! >> %LOG%
HTH Biber
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
... echo Die Dateien %%~nI sind nicht gleich groß! >> %LOG%
HTH Biber
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
Gruß André
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
Gruß André
Moin André,
...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.
Schönes Wochenende
Frank / der Biber aus Bremen
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
Es ist mir schon klar, dass es wenig Sinn macht ein Log-Datei mit jedem Eintrag neu anzulegen
...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.
Schönes Wochenende
Frank / der Biber aus Bremen
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
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
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é
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é
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.
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.
