Kopierfehler bei Festplatten-Wiederherstellung / zu große Festplatte?

[MacLenburg]

Hallo Forum,

lese hier seit längerem mit, jetzt bin ich aber auf ein Problem gestoßen, zu dem ich nirgendwo etwas finden konnte. Vor ein paar Monaten bin ich mit meinen Daten (ca. 2,6 TB) auf eine neu gekaufte 6 TB-Festplatte umgezogen, und zwar per Wiederherstellung über das Festplatten-Dienstprogramm. Jetzt habe ich zu meinem Erschrecken festgestellt, daß ein signifikanter Teil der Dateien - vielleicht so etwa ein Viertel - beschädigt ist, so daß sie sich nicht mehr öffnen lassen. Ein Muster ist nicht zu erkennen - defekte und intakte Dateien sind bunt gemischt. Glücklicherweise habe ich die alte Platte noch, so daß ich die defekten Dateien erneut auf die neue Platte ziehen kann - die Originale sind in Ordnung, so daß das Ganze wenigstens keinen Datenverlust bedeutet. Trotzdem ist es natürlich hochgradig irritierend, wenn man sich nicht darauf verlassen kann, daß so ein Umzug reibungslos funktioniert.

Hat irgendwer von Euch so etwas schon einmal beobachtet?

Die Systemkonfiguration:
Mac Pro Mitte 2010
El Capitan 10.11.6
Quellvolume: WD30ZRX ("WD green")
Zielvolume: WD60EZRZ ("WD blue")
Systemvolume: WD30EZRZ ("WD blue")

Das Festplatten-Dienstprogramm zeigt keine Auffälligkeiten der Platte an (SMART-Status "überprüft"; "Erste Hilfe" fördert keine Probleme zu Tage), allerdings habe ich kein Programm, mit dem ich einen detaillierten SMART-Check machen kann (wäre da Etrecheck das Mittel der Wahl, oder gibt es gute/bessere Alternativen?).

Allerdings hat Apple den Mac Pro seinerzeit meines Wissens mit maximal 4 x 2 TB-Platten ausgestattet; da liege ich entschieden drüber und frage mich, ob ich meinen Rechner hinsichtlich der eingebauten HDDs überfordert habe. Andererseits bietet OWC für dieses Modell 8, 12 und 14 TB-Platten an (und gibt 16 TB als Ausbaugrenze an), das spricht ja doch für erhebliches Potential des Rechners. Es ist natürlich klar, daß ein Dritthersteller nie so schlau ist wie der Originalhersteller und nicht sämtliche Konstellationen durchtesten kann, nur hätte ich vermutet, daß der Mac eine Festplatte entweder akzeptiert (und dann klaglos damit umgeht) oder, wenn er sie nicht zuverlässig verwalten kann, von vornherein eine Fehlermeldung ausgibt. Zudem finden sich (wenn auch sehr sporadisch) Hinweise darauf, daß der 2010er Mac Pro gut mit ziemlich großen Platten zurecht kommt - über Probleme habe ich da bisher nichts gefunden.

Was denkt Ihr hierüber?

 

[Wuchtbrumme]

der Mac Pro hat keine Beschränkung. Wenn 20TB-Platten käuflich erhältlich sein werden, werden die auch laufen. Und wenn die Hardware in Ordnung wäre, müssten die Daten auch korrekt kopiert worden sein. Dafür spricht ja auch, dass Du sagst,, dass kaputte und korrekte Dateien bunt gemischt seien. Wie gesagt, es ist kein generelles oder grundsätzliches Problem.

Wie hast Du kopiert?
Wie oder woran stellst Du jetzt fest, dass die Daten kaputt sind?
Hast Du einen Speichertest (RAM) gemacht?
Kennst Du FolderSync Pro?

 

[MacLenburg]

Kopiert habe ich per Wiederherstellung im FP-Dienstprogramm, d.h. ich habe den Inhalt der gesamten Platte auf einen Rutsch auf die neue Platte übertragen - oder besser gesagt: das war meine Absicht.

Die Daten sind definitiv zum Teil hinüber. Die betroffenen JPG-Dateien lassen sich weder in Photoshop noch in Vorschau öffnen (Photoshop meldet "Could not complete your request because an unknown or invalid JPEG marker type is found"); außerdem zeigt der Finder von diesen Dateien keine Thumbnails an. Die betroffenen RAW-Dateien werden zum Teil vom RAW-Konverter gar nicht erst erkannt, während einige offenbar weniger schwere Fälle über einen Teil des Bildes Farbrauschen und farbige Muster zeigen - sind damit aber natürlich trotzdem unbrauchbar. Wie gesagt: alle entsprechenden Ursprungsdateien auf der alten Platte, die ich bisher getestet habe, sind völlig in Ordnung.

Der Hinweis auf einen Hardware-Defekt ist ein interessanter Punkt, wobei der Rechner sich allerdings weder vor dem besagten Kopiervorgang noch in den 6 Wochen danach irgendetwas hat anmerken lassen - kein einziger Absturz, keine nicht geladenen Extensions, nichts... wobei mir schon klar ist, daß das alleine noch nicht viel bedeutet, nur gibt es sonst keine anderen Indizien für einen Hardwarefehler. Den RAM hätte ich ganz gerne mal getestet, leider bringe ich den Apple Hardware-Test nicht zum Laufen, weder mit "D" noch mit "Alt + D", warum auch immer. Allerdings sagt man dem AHT ja auch eher begrenzte Aussagekraft nach, so daß ich daher noch keine Tränen vergossen habe. Womit würdest Du den Speicher testen?

Nein, FolderSync Pro kenne ich nicht - ich bin allerdings auch sehr zurückhaltend damit, mir neue Software anzuschaffen; ich halte meinen Rechner da so aufgeräumt wie möglich. An den Gedanken einer automatischen Synchronisation konnte ich mich auch noch nicht gewöhnen, weil ich da immer die Befürchtung habe, daß etwas Unerwünschtes abläuft, so praktisch das im Prinzip sein mag. Das Kopieren mache ich daher immer lieber händisch, auch wenn es mehr Arbeit bedeutet. Du erwähnst das Programm hier aber wegen der Möglichkeit, den Inhalt von Quell- und von Zielvolumen miteinander zu vergleichen?

 

[Wuchtbrumme]

Kopiert habe ich per Wiederherstellung im FP-Dienstprogramm, d.h. ich habe den Inhalt der gesamten Platte auf einen Rutsch auf die neue Platte übertragen - oder besser gesagt: das war meine Absicht.

das ist nicht die beste Art, Dateien zu kopieren. Ursprünglich war die Funktion glaube ich eine Art dd zum sektorbasierten Kopieren eines Blockdevices, wurde dann aber immer mehr aufgebohrt und verändert. Heute macht es für APFS komplett anderes. Deshalb hatte ich eigentlich FolderSync Pro erwähnt - aber jedes rsync funktioniert (FolderSync Pro ist ja auch nur eine Wrapper-GUI, wobei sich der Autor sehr viel Mühe gegeben hat).

Die Daten sind definitiv zum Teil hinüber. Die betroffenen JPG-Dateien lassen sich weder in Photoshop noch in Vorschau öffnen (Photoshop meldet "Could not complete your request because an unknown or invalid JPEG marker type is found"); außerdem zeigt der Finder von diesen Dateien keine Thumbnails an. Die betroffenen RAW-Dateien werden zum Teil vom RAW-Konverter gar nicht erst erkannt, während einige offenbar weniger schwere Fälle über einen Teil des Bildes Farbrauschen und farbige Muster zeigen - sind damit aber natürlich trotzdem unbrauchbar.

Ich kenne keinen Hardwarefehler, der nur Teile von Daten korrumpiert, daher mag ich das auch eher ausschließen. Es gingen noch defekte Sektoren auf der Ursprungsplatte als Erklärung für wenige Defekte, aber da solltest Du im Systemlog eigentlich entsprechende IO-Fehler sehen können.

Den RAM hätte ich ganz gerne mal getestet, leider bringe ich den Apple Hardware-Test nicht zum Laufen, weder mit "D" noch mit "Alt + D", warum auch immer.

es ist eine spezielle Software, die Du wohl mal gelöscht hast. Wenn Du die originalen DVDs noch hast, einlegen, neustarten und direkt vor/beim Gong D drücken und gedrückt halten (am besten auf einer verkabelten Tastatur).

Womit würdest Du den Speicher testen?

Rember oder memtest86+.

Nein, FolderSync Pro kenne ich nicht - ich bin allerdings auch sehr zurückhaltend damit, mir neue Software anzuschaffen; ich halte meinen Rechner da so aufgeräumt wie möglich. An den Gedanken einer automatischen Synchronisation konnte ich mich auch noch nicht gewöhnen, weil ich da immer die Befürchtung habe, daß etwas Unerwünschtes abläuft, so praktisch das im Prinzip sein mag. Das Kopieren mache ich daher immer lieber händisch, auch wenn es mehr Arbeit bedeutet. Du erwähnst das Programm hier aber wegen der Möglichkeit, den Inhalt von Quell- und von Zielvolumen miteinander zu vergleichen?

mir ging es tatsächlich nicht um den automatischen Sync, den ich bei sowas wie bei meiner Fotobibliothek auch lieber nicht benutzen würde, sondern wie Du schon schreibst, um die Möglichkeit, Dateien binär vor und nach dem Kopieren zu vergleichen.

Wenn Du kannst, lösche die neue Festplatte komplett, lege ein neues HFS+-Dateisystem an und kopiere die Daten, am besten über rsync, da bei Abbrüchen der Finder ein wenig komfortables Tool ist.

Schau auch mal ins Systemlog (Dienstprogramme/Konsole) und schau während des Kopierens, ob Du da Fehler siehst. Natürlich kannst Du, wenn Du rsync eh schon im Terminal benutzt, auch gleich die Fehlerausgabe in eine Logdatei schreiben.

 

[MacAlzenau]

Es gingen noch defekte Sektoren auf der Ursprungsplatte als Erklärung für wenige Defekte, aber da solltest Du im Systemlog eigentlich entsprechende IO-Fehler sehen können.

Dem ersten Post zufolge sind die Originale ja in Ordnung. Defekte Sektoren kommen also höchstens auf der neuen großen Platte in Frage.

 

[MacLenburg]

das ist nicht die beste Art, Dateien zu kopieren. Ursprünglich war die Funktion glaube ich eine Art dd zum sektorbasierten Kopieren eines Blockdevices, wurde dann aber immer mehr aufgebohrt und verändert.

Hmm - historisch hast Du sicher Recht, aber es dürfte eigentlich nicht Arten zu kopieren erster und zweiter Klasse geben, zumindest nicht hinsichtlich der Zuverlässigkeit (wohl aber natürlich, was den Komfort betrifft). Solange OS-X zulässt, eine HD auf eine bestimmte Weise zu kopieren, muss man als Anwender auch erwarten können (und kann es wohl normalerweise auch), daß das Ergebnis in Ordnung ist. Das ist ja das, was mich hier so irritiert: daß mir völlig unklar ist, was da passiert sein könnte.

Heute macht es für APFS komplett anderes.

Bei mir hat es auch scheinbar etwas komplett anderes gemacht, aber noch auf OS extended (journalded) Volumes...

es ist eine spezielle Software, die Du wohl mal gelöscht hast. Wenn Du die originalen DVDs noch hast, einlegen, neustarten und direkt vor/beim Gong D drücken und gedrückt halten (am besten auf einer verkabelten Tastatur).

OK, da fahnde ich mal; die sollten noch irgendwo liegen. Außerdem schaue ich mir mal die beiden Speicherprüfprogramme an, die Du genannt hast.

Wenn Du kannst, lösche die neue Festplatte komplett, lege ein neues HFS+-Dateisystem an und kopiere die Daten, am besten über rsync, da bei Abbrüchen der Finder ein wenig komfortables Tool ist.

Auch mit rsync werde ich mich mal befassen (habe ich noch nie benutzt), allerdings habe ich beim Kopieren eigentlich auch nie (soweit ich mich erinnern kann) Abbrüche erlebt.

Schau auch mal ins Systemlog (Dienstprogramme/Konsole) und schau während des Kopierens, ob Du da Fehler siehst. Natürlich kannst Du, wenn Du rsync eh schon im Terminal benutzt, auch gleich die Fehlerausgabe in eine Logdatei schreiben.

Klingt sinnvoll, allerdings geht das etwas über meine bisherigen Kenntnisse heraus; mit der Konsole habe ich noch nie ernsthaft gearbeitet, und mit dem Terminal nur sporadisch. Ich taste mich an das Thema mal heran.

Defekte Sektoren kommen also höchstens auf der neuen großen Platte in Frage.

Ich hatte ohnehin schon überlegt, mir Etrecheck zuzulegen, dann kann ich der neuen Platte mal auf den Zahn fühlen.

Also - meine Hausaufgaben dürften klar sein. Wird ein paar Tage dauern, bis ich klarer sehe - ich melde mich dann wieder mit meinen Erkenntnissen. Für heute erst einmal vielen Dank für Eure hilfreichen Kommentare!

 

[Wuchtbrumme]

Ich hatte ohnehin schon überlegt, mir Etrecheck zuzulegen, dann kann ich der neuen Platte mal auf den Zahn fühlen.

SMARTReporter TryOut.
Ansonsten kann man sich kostenlos das SMARTReporter Tryout besorgen (http://www.corecode.at/smartreporter/, das Tryout kostet kein Geld), dieses starten, dann auf Überprüfungen, S.M.A.R.T., dann auf Fortgeschrittene Werkzeuge, dann "Attribute zeigen" in der Zeile Deiner Systemfestplatte. Die dann Copy&Paste hier rein. Falls Du die smartmontools (Terminal) installiert hast, so geht es auch damit (einfacher: smartctl -a disk0).

 

[MacLenburg]

Es wird immer bizarrer. Den Hardware-Test konnte ich noch nicht machen (an meine Installation-DVDs komme ich erst in ein oder zwei Wochen heran, und neue Software wäre dann erst der nächste Schritt), aber ich habe jetzt mal ein paar der betroffenen Ordner verglichen. Was wirklich befremdlich ist: bei gleicher Objektzahl unterscheiden sich Original und defekte Kopie in ihrer Größe entweder gar nicht, oder die Kopie ist größer als das Original, oder sie ist kleiner. Was noch verrückter ist: in zwei verschiedenen Fällen fehlen dem kopierten Ordner genau 6148 Byte, das kann ja wohl kaum Zufall sein (und entspricht auch nicht der Größe einer Datei - die sind alle größer). Ist mir völlig schleierhaft, was da passiert ist - als hätte jemand nach dem Kopiervorgang an den Daten herumgepfuscht, aber dies sind alles Dateien, die ich nach dem Kopieren nicht mehr angefasst hatte. Eines ist mir aber im log der Wiederherstellung aufgefallen: nach dem eigentlichen Vorgang aus Wiederherstellen und Überprüfen gab es noch einmal eine zweite Wiederherstellen-Überprüfen-Session. Ist das normal, oder könnte das einen Hinweis auf einen fehlerhaften Kopiervorgang sein?

2020-12-13 00:18:45 +0100: Wiederherstellen starten …
2020-12-13 00:18:46 +0100: Ziel überprüfen …
2020-12-13 00:18:46 +0100: Fertig
2020-12-13 00:18:46 +0100: Quelle überprüfen …
2020-12-13 00:18:46 +0100: Fertig
2020-12-13 00:18:48 +0100: Größen überprüfen …
2020-12-13 00:18:49 +0100: Fertig
2020-12-13 00:18:54 +0100: Wiederherstellen
2020-12-13 04:42:32 +0100: Überprüfen
2020-12-13 08:08:44 +0100:
2020-12-13 08:08:55 +0100: Wiederherstellen
2020-12-13 08:09:04 +0100: Überprüfen
2020-12-13 08:09:10 +0100:
2020-12-13 08:09:10 +0100: Ziel-Volume erneut aktivieren …
2020-12-13 08:09:10 +0100: Fertig
2020-12-13 08:09:11 +0100: Wiederherstellung dauerte 7 Stunden, 50 Minuten
2020-12-13 08:09:11 +0100: Abgeschlossen.

 

[Wuchtbrumme]

Du hast noch ein weiteres Backup dieser Festplatte? Ist das Dateisystem mit der Quelle der Bilder in Ordnung (1. Hilfe im Festplattendienstprogramm)?

Kannst Du eine kaputte Datei und deren intakte Quelle bereitstellen?

 

[Marcel Bresink]

aber ich habe jetzt mal ein paar der betroffenen Ordner verglichen.

Du hast leider Wuchtbrummes Rückfragen nicht beantwortet. Wie machst Du das? Und woran stellst Du fest, dass an der Kopie etwas nicht stimmt?

Was wirklich befremdlich ist: bei gleicher Objektzahl unterscheiden sich Original und defekte Kopie in ihrer Größe entweder gar nicht, oder die Kopie ist größer als das Original, oder sie ist kleiner.

Das kann völlig normal sein, je nach dem ob man die physische Größe oder die Nenngröße der Daten zum Vergleich heranzieht. Die Kopie der Festplatte kann optimiert sein, weil der Verschnitt zwischen Dateigrößen und Blockgrößen besser ausgenutzt wird.

Eines ist mir aber im log der Wiederherstellung aufgefallen: nach dem eigentlichen Vorgang aus Wiederherstellen und Überprüfen gab es noch einmal eine zweite Wiederherstellen-Überprüfen-Session. Ist das normal,

Ja, das ist normal. Wenn Du die ganze Platte wiederherstellst, betrifft dies bei OS X El Capitan die Partition mit den eigentlichen Nutzdaten und die Partition mit dem Wiederherstellungsbetriebssystem.

 

[MacLenburg]

Du hast noch ein weiteres Backup dieser Festplatte?

Ja - ich habe den Inhalt der Festplatte vor ein paar Monaten archiviert, allerdings lagert diese Kopie am anderen Ende der Republik, so daß ich da nicht so schnell herankomme. Muß ich aber natürlich überprüfen, ob dieses Archiv in Ordnung ist oder auch einen Defekt hat. Immerhin habe ich das Archiv auf andere Weise erzeugt (nicht über disk utility, sondern über den Finder), so daß es gute Chancen geben sollte, daß diese Kopie in Ordnung ist.

Ist das Dateisystem mit der Quelle der Bilder in Ordnung (1. Hilfe im Festplattendienstprogramm)?

Ich habe die 1. Hilfe einen guten Monat vor dem Kopiervorgang laufen lassen - das sah m.E. in Ordnung aus:


2020-11-08 20:43:13 +0100: Überprüfung wird gestartet:
2020-11-08 20:43:22 +0100: Speichersystem prüfen
2020-11-08 20:43:22 +0100: Volume wird überprüft
2020-11-08 20:43:22 +0100: disk3s2: Suchen nach Volume Headers
2020-11-08 20:43:22 +0100: disk3s2: Suchen nach Disk Labels
2020-11-08 20:43:22 +0100: Logische Volumegruppe 3E6D78B0-7BE5-4BE5-A8F9-F662FE244D6B auf 1 Gerät
2020-11-08 20:43:22 +0100: disk3s2: Suchen nach Metadata Volume
2020-11-08 20:43:22 +0100: Logische Volumegruppe besitzt ein 24 MB Metadaten-Volume mit double Redundanz
2020-11-08 20:43:22 +0100: Suche nach gültigen Checkpoint in Metadaten starten
2020-11-08 20:43:22 +0100: Segment Headers laden und überprüfen
2020-11-08 20:43:22 +0100: Checkpoint Payload laden und überprüfen
2020-11-08 20:43:22 +0100: Transaction Segment laden und überprüfen
2020-11-08 20:43:22 +0100: Transaction Segment laden und überprüfen
2020-11-08 20:43:22 +0100: 1 neueste Non-Checkpoint-Transaktion integrieren
2020-11-08 20:43:22 +0100: Virtual Address Table laden und überprüfen
2020-11-08 20:43:22 +0100: Segment Usage Table laden und überprüfen
2020-11-08 20:43:22 +0100: Metadata Superblock laden und überprüfen
2020-11-08 20:43:22 +0100: Logical Volumes B-Trees laden und überprüfen
2020-11-08 20:43:22 +0100: Logische Volumegruppe enthält 1 logisches Volume
2020-11-08 20:43:22 +0100: BE68CB67-0497-4CE7-B4E6-0E22C92AD2A8 laden und überprüfen
2020-11-08 20:43:22 +0100: 3BC488D6-4FBA-40F1-B7AE-4E3C2A536952 laden und überprüfen
2020-11-08 20:43:22 +0100: Freespace Summary laden und überprüfen
2020-11-08 20:43:22 +0100: Block Accounting laden und überprüfen
2020-11-08 20:43:22 +0100: Live Virtual Addresses laden und überprüfen
2020-11-08 20:43:22 +0100: Neuester Wiederaufsetzpunkt für Transaktion ist gültig
2020-11-08 20:43:22 +0100: Segment Cleaning laden und überprüfen
2020-11-08 20:43:22 +0100: Das Volume „3E6D78B0-7BE5-4BE5-A8F9-F662FE244D6B“ ist anscheinend in Ordnung
2020-11-08 20:43:24 +0100: Dateisystem prüfen
2020-11-08 20:43:24 +0100: Live-Verifizierung durchführen.
2020-11-08 20:43:24 +0100: HFS+ Volume (Journaled) überprüfen.
2020-11-08 20:43:24 +0100: Zusatzdatei für Dateiaufbau wird überprüft.
2020-11-08 20:43:29 +0100: Multi-Link-Dateien werden überprüft.
2020-11-08 20:43:30 +0100: Datei für erweiterte Attribute wird überprüft.
2020-11-08 20:43:35 +0100: Repariert:
2020-11-08 20:43:35 +0100:


Von da an war die Platte nicht viel in Betrieb, so daß ein in der Zwischenzeit aufgetretener Defekt nicht übermäßig wahrscheinlich erscheint (aber natürlich nicht auszuschließen ist). Augenblicklich möchte ich an der Platte am liebsten so wenig wie möglich rühren, bevor ich eine mit Sicherheit vollständig intakte Kopie davon habe, daher scheue ich mich davor, Erste Hilfe erneut zu starten (wenn ich mich richtig entsinne, ist bei El Capitan im Gegensatz zu beispielsweise Mavericks die Analyse und die Reparatur zusammengefasst - das ist mir in der momentanen Situation ein wenig unheimlich). Der jetzige Plan ist, zunächst eine neue Kopie auf eine andere Platte anzufertigen und diese zu verifizieren - auf die Couch kommt die Quellplatte dann anschließend.

Kannst Du eine kaputte Datei und deren intakte Quelle bereitstellen?

Klar, gerne. Ich habe mal ein Paar JPGs und ein Paar RAW-Dateien herausgesucht - wie schon gesagt läßt sich die JPG-Kopie nicht öffnen (zumindest nicht in den normalerweise dafür verwendeten Programmen), und die RAW-Datei lässt sich nicht in eine intakte Bilddatei konvertieren. Allerdings sind diese Dateien relativ groß (24 MB / 43 MB), so daß ich erst einmal ausprobieren muß, ob ich sie hier hochladen kann - probiere ich gleich in einem separaten Post. Das Merkwürdige ist, daß ich den defekten Dateien im Finder nichts ansehen kann (von der fehlenden Vorschau abgesehen) - gleiche Größe, gleiches Änderungsdatum.

Das kann völlig normal sein, je nach dem ob man die physische Größe oder die Nenngröße der Daten zum Vergleich heranzieht. Die Kopie der Festplatte kann optimiert sein, weil der Verschnitt zwischen Dateigrößen und Blockgrößen besser ausgenutzt wird.

Hmm, klingt einerseits einleuchtend... aber dann dürften doch kopierte Ordner nicht größer werden als das Original? Hier mal ein paar Beispiele (die Zahlen bedeuten Zahl der Objekte / ungefähre Ordnergröße / Größenänderung:

Ordner 1: 361 / 15,03 MB / -6148 Byte
Ordner 2: 168 / 6,37 MB / +19464 Byte
Ordner 3: 135 / 3,07 MB / +/- 0 Byte
Ordner 4: 365 / 15,39 MB / -6148 Byte

Ja, das ist normal. Wenn Du die ganze Platte wiederherstellst, betrifft dies bei OS X El Capitan die Partition mit den eigentlichen Nutzdaten und die Partition mit dem Wiederherstellungsbetriebssystem.

Das ist aber keine Systemplatte, sondern eine reine Datenplatte. Eine Wiederherstellungspartition sollte es da doch nicht geben, oder?

Du hast leider Wuchtbrummes Rückfragen nicht beantwortet. Wie machst Du das? Und woran stellst Du fest, dass an der Kopie etwas nicht stimmt?

Der Ausgangspunkt war, daß sich ein Teil der Dateien nicht mehr öffnen lässt ("invalid JPEG marker" sowie nicht mehr konvertierbare RAW-Dateien). Den Vergleich der Ordner habe ich bisher händisch (und nur stichprobenartig) im Finder vorgenommen. Ich werde da noch einen vernünftigen Vergleich drüberlaufen lassen, aber das mache ich lieber erst, wenn ich eine vollständig intakte Kopie habe (voraussichtlich auf eine andere Zielplatte); bis dahin packe ich mein Quelllaufwerk in Watte.

Kannst Du eine kaputte Datei und deren intakte Quelle bereitstellen?

So, inzwischen muß ich vermelden, daß der upload leider nicht funktioniert - die RAW-Dateien werden gleich ausgegraut angezeigt, die JPGs zählen hoch bis 100%, und dann kommt die Meldung, daß sie zu groß sind (bzw. bei der Kopie meckert die Forumsseite dann noch mit "Die hochgeladene Datei war nicht wie erwartet ein Bild" (QED)). Gibt es da einen Workaround für uploads größerer Dateien? Leider kann ich in diesem Fall ja keine höhere JPG-Kompression verwenden...

 

[Wuchtbrumme]

Kannst Du eine kaputte Datei und deren intakte Quelle bereitstellen?

So, inzwischen muß ich vermelden, daß der upload leider nicht funktioniert - die RAW-Dateien werden gleich ausgegraut angezeigt, die JPGs zählen hoch bis 100%, und dann kommt die Meldung, daß sie zu groß sind (bzw. bei der Kopie meckert die Forumsseite dann noch mit "Die hochgeladene Datei war nicht wie erwartet ein Bild" (QED)). Gibt es da einen Workaround für uploads größerer Dateien? Leider kann ich in diesem Fall ja keine höhere JPG-Kompression verwenden...

das war auch nicht das Ziel; die Dateien muss man sich mal binär anguckden und vor allem, die Quelldatei und die defekte Kopie davon, was da geändert ist. Man braucht also die originale Datei und die kaputte Kopie, es reicht nicht irgendeine.

Hmm, klingt einerseits einleuchtend... aber dann dürften doch kopierte Ordner nicht größer werden als das Original?

das ist Wurscht
Wenn man Quelle und Ziel vergleichen möchte, vergleicht man am besten die Einzeldateien binär. Dafür bietet sich ein Duplikatscanner mit passender Option an oder wie gesagt, das Kopier- oder Syncprogramm könnte auch gleich eine Option dafür haben.