Wie Copy mit Verify?

[nehonimo]

Hallo,

Nachtrag: Habe Win7

es geht um Fotos von einer SD Karte auf die Festplatte zu kopieren.
In der Vergangenheit hatte ich einmal das Problem, das die Fotos nach dem Kopieren der SD Karte auf HDD dort nicht richtig angezeigt werden konnte. In der Kamera ging die Karte noch und ich konnte die Bilder per USB Kabel übertragen.

Seit dem ist meine Vorgehensweise mit Total Commander:
Kopieren der Daten und dann bei Syncronisieren der Directories und dort Compare by Content.
Bisher seit Jahren alles ok.

Jetzt möchte ich gerne per script machen. Habe ein wenig gegoogled und dort gelesen, dass man zwar für das copy ein verify über /V einschalten kann, dies aber nur prüft, ob die kopierte Datei geöffnet werden kann, aber nicht ob die Dateien Bitweise identisch sind.

Was könnt ihr empfehlen für copy mit echtem Verify?
Oder lieber in zwei schritten, erst copy und dann alle Dateien über verify?
Bei zwei Schritten mit fc /B oder comp ?

Falls es einen besseres Forum gibt, wo es passt, bitte verschieben.


Gruß nehonimo

 

[xmarsx]

XXCOPY (http://www.xxcopy.com/)
Der /V2 Parameter sollte Deinen Wunsch erfüllen: http://www.xxcopy.com/xxtb_045.htm

Unter OS/2 bzw. eCS vertraue ich weiter darauf das "XCOPY .... /H /O /T /S /E /R /V" vernünftig arbeitet. Habe damit gerade erst meine Daten auf eine neue JFS Partition von meiner alten Daten Festplatte auf neue SSD migriert.

 

[powerfx]

TeraCopy macht das z.B.
Es kann den default Copy/Paste-Handler von Windows ersetzen und so bei Kopieren CRC-Checks durchführen.

 

[nehonimo]

Danke.

Wenn ich das jetzt auf den HP's richtig verstanden habe, dann ist
TeraCopy kein cmd tool. Beim CRC vermute ich, dass es von der source beim lesen den crc bildet und dann auf Destination schreibt. Danach Destination nochmal liest und wieder den CRC bildet. Dann werden die CRCs verglichen. Würde source und Destination erneut gelesen, dann könnte man ja Byte by Byte vergleichen und müsste keinen crc machen. Ich vermute daher, dass dadurch nur geprüft werden kann, ob richtig geschrieben wurde und dies auch identisch lesbar ist.
Mein Problem war aber ein defect der source, d.h. mehrmaliges lesen lieferte unterschiedliche Daten. Daher sollte nach dem copy nochmal neue beides gelesen und verglichen werden.

xxcopy:
ich verstehe /CD:U so, dass hier binäre verglichen wird und ungleiche Dateien neu kopiert werden?
Vielleicht kann man das so starten und wenn nichts kopiert wurde, dann ist die SD Karte in Ordnung.
Evtl. mal prüfen, ob es bei "nicht kopieren" einen errorlevel gibt, den man im script abfragen kann.

Ansonsten bleibt wohl nur fc oder comp. Beide kann man über errorlevel abfragen.
Hat jemand Erfahrung bzgl. Geschwindigkeit oder ist eins der beiden zu bevorzugen?

Gruß nehonimo

 

[xmarsx]

xxcopy:
ich verstehe /CD:U so, dass hier binäre verglichen wird und ungleiche Dateien neu kopiert werden?
Vielleicht kann man das so starten und wenn nichts kopiert wurde, dann ist die SD Karte in Ordnung.
Evtl. mal prüfen, ob es bei "nicht kopieren" einen errorlevel gibt, den man im script abfragen kann.

Ja, mit dem /CDU Switch sehe ich es auch so, dass alle Dateien die nicht Quelle entsprechen kopiert werden (kopiere alle veränderten Dateien und neuen Dateien).
Die Chance das die SDCard nicht in Ordnung ist würde ich aber ich höher einstufen als einen Fehler auf der Festplatte.
Lässt Du also alles auf der SDCard und kopierst quasi immer alles auf die Festplatte was sich von der SDCard unterscheidet kann das auch nach hinten los gehen...und zwar genau dann, wenn die SDCard beschädigt ist.
Dann kopierst Du im Zweifel "defekte" Daten über die funktionstüchtigen Daten auf der Festplatte.

Hier noch weitere Details zu den XXCOPY Parametern:
Quelle: http://www.xxcopy.com/old/

Ver 2.98.0 is a bugfix release.
This release is made in to fix a bug in the /CDU and /CDM functions.
The feature is designed to make an air-tight testing in incremental
backup operations (/BI and similar choices) that assumes that the
timestamp and/or the file size sufficiently determine the need for
a backup. With the /CDU switch in addition to /BI, XXCOPY will
check the file in the destination directory against its counterpart
in the source on a byte-by-byte basis to determine the need for backup.

XXCOPY's attempt to preserve the LastAccess timestamp of the source
file after the file contents were read in the course of a file copy
generated an error message with a write-protected source volume.
Now, with a pre-testing of such a condition, the error message dialog
is suppressed.

und
Quelle: http://www.xxcopy.com/img/

Data-Comparison functions added
Pprevious versions of XXCOPY supported the file data comparison on
a byte-by-byte basis as a verify operation immediately after the file
is copied. However, XXCOPY lacked the ability to compare file contents
in any other context. Starting with Ver 2.96.3, a new set of switches,
/CDM, /CDU, /CDX and /CD0 are added to address the needs that a number
of users requested in the past. These switches perform a file-selection
operation on their own, or in combination with other file-selection
switches.


/CDM // Compares file data and selects the file if matched.
/CDU // Compares file data and selects the file if unmatched.
/CDX // Selects the file if unmatched and brand new files.
/CD0 // Does not compare file data (default).

The three switches are mutually exclusive (if two or more such switches
are specified, the last one will prevail). They can be combined with
any other switches.

E.g.:

xxcopy \src\ \dst\ /bi /cdu // skip files that match exactly
xxcopy \src\ \dst\ /clone /cdu // combine with the popular switch

In the above examples, the addition of the /CDU switch makes
sure the incremental backup operation does not take chances in
determining files that are truly identical. A file in the
source directory that matches in the timestamp and the size to
its counterpart in the destination directory will be further
scrutinized by a byte-by-byte comparison before treated as
truly identical. Without the /CDU switch, the files with
matching timestamp and filesize will be skipped even though
there is a small possibility that the file contents vary.
Although the favorable assumption (without the use of /CDU)
is reasonable and necessary for speedy operation, the new
feature satisifies demainding users' needs.