Unterschiedl. SHA-Werte, obwohl Synchronisation mittels Grsync ohne Fehlermeld.

[anno_2020]

In erster Linie ging es mir dort um die Erklärung, warum unter bestimmten Umständen bei der Abfrage mit "du" unterschiedliche Werte ausgegeben werden können.

Ja, aber SHA-Werte sind doch anscheinend ein etabliertes Verfahren, um die Korrektheit von Downloads (oder hier: Kopien) zu überprüfen, oder nicht? -

Da ich für meine .zip-Dateien eh schon SHA256-Werte hatte, war ich jedenfalls zufrieden, dort auch einen Befehl für Ordner zu finden.

Du zweifelst die Ausgabe von rsync an,

Und das Problem zum damaligen Zeitpunkt war ja, das auch Grsnyc noch Fehlermeldungen ausgab. - Also meine Zweifel, ob das Kopieren korrekt geklappt hat, nicht einfach von irgendwo her kamen.

[Whitie]

Rückfragen:

Im Quellverzeichnis könnte z. B. noch eine versteckte Datei sein, die nicht mitkopiert wird

Falls die da sind, dann werde sie da ja auch einen Sinn haben (und folglich würde ich sie mitkopieren wollen), oder nicht?

Probier einfach mal den Befehl ohne die Pipe's aus und vergleiche

Was sind denn Pipes überhaupt?

(nimm ein Verzeichnis mit wenig Dateien).

Dass der Code im Prinzip funktioniert, hatte ich ja gestern (mit übereinstimmenden Werten) schon für mein Verzeichnis 1 festgestellt; auch für Verzeichnis 2 wurden mir gestern Werte ausgegeben - nur halte nicht übereinstimmende.

Pipe's sind die "Striche |". Damit leitet man die Ausgabe eines Befehls auf die Standardeingabe des nächsten Befehls.
Man könnte z. B. mal

Code: [Auswählen]

$ find . -type f | wc -lprüfen. Das zählt die Dateien und durch weglassen des Hashes geht es auch schnell.
Falls die Anzahl nicht stimmt, könnte man mit

Code: [Auswählen]

$ find . -type f
oder sortiert
$ find . -type f | sort -k2,2alle gefundenen Dateien ansehen/vergleichen. Ist allerdings mühsam, würde ich jeweils in eine Datei leiten und dann per Diff angucken.

Code: [Auswählen]

$ cd Quelle
$ find . -type f | sort -k2,2 > /home/$USER/Quelle.txt
$ cd Ziel
$ find . -type f | sort -k2,2 > /home/$USER/Ziel.txt
$ cd ~
$ vimdiff Quelle.txt Ziel.txtWenn die Anzahl stimmt, das ganze mit Hash nochmal. Im Diff sieht man dann ganz genau welche Dateien nicht übereinstimmen.

P. S. Natürlich sollten versteckte Dateien mit kopiert werden. Ich würde trotzdem prüfen, ob das auch so ist.

Gruß
Whitie

[anno_2020]

Vielen Dank.

1.

Ich habe inzwischen den zweitgrößten Unterordner (zwei .zip-Dateien; zusammen fast 9,5 GB) abgeglichen:

+ Berechnung dauerte jeweils nur wenige Minuten; Werte stimmten aber zunächst nicht überein.

Sodann Abgleich der SHA256-Werte der beiden einzelnen Dateien:

+ Deren Werte stimmen überein.

In diesem Unterordner ist nichts weiter; auch mit "Verborgene Dateien anzeigen" wird mir im Dateimanager nichts Weiteres angezeigt.

Dann noch mal den SHA1-Abgleich für diesen Unterordner gemacht: Nun auf einmal Übereinstimmung auf Quell- und Ziel-Laufwerk.

2.

Es hakt noch an dem größten Unterordner in Verzeichnis 2 (rund 1 Mio. Objekte; ca. 6 GB).

a) Auf Quell- und Ziel-Laufwerk in diesem Ordner jeweils:

Code: [Auswählen]

find . -type f | wc -l
Übereinstimmende Ausgabe (jeweils fast eine halbe Mio.).

b) Dann nun also noch mal auf beiden Laufwerken für diesen Ordner:

Code: [Auswählen]

find . -type f \( -exec sha1sum "{}" \; \) | sort -k2,2 | sha1sum
Wird ein Weilchen dauern; melde mich dann später noch mal.

[anno_2020]

Auch dies ist jetzt auf beiden Laufwerken durchgelaufen:

+ Auf der kleineren SSH-(Ziel-)Festplatte dauerte es ca. eine halbe Stunde.

+ Auf der viermal so großen HDD-(Quell-)Festplatte ca. 1 1/2 Stunde.

Die SHA1-Werte sind weiter unterschiedlich; ich werde nun auf noch tieferer Ordnerebene weiter machen.

[anno_2020]

Nächster Schritt:

+ Wie gesagt, es geht um zwei Verzeichnisse. Verzeichnis 1 ist in Ordnung (übereinstimmende SHA1-Werte).

+ Für Verzeichnis 2 stimmen die SHA1-Werte nicht überein, wobei sich das Problem dort auf den größten Unterordner konzentriert (die anderen dortigen Unterordner und Dateien haben übereinstimmende SHA1- bzw. SHA256-Werte).

+ Jener größte Unterordner hat seinerseits genau einen Unter-Unterordner. Darunter sind noch einmal drei Ordner.

+ Von letzteren hat Ordner 1 rund 600 Dateien; die SHA1-Werte für Ordner 1 stimmen auf Ziel- und Quell-Laufwerk überein. Die Berechnung dauerte nicht lange.

+ Update: Ordner 2 hat auf beiden Laufwerken knapp 5.000 Dateien. SHA1-Werte stimmen ebenfalls überein.

+ Nun also der dritte (und letzte Ordner): Weiteres Update folgt.

[anno_2020]

+ Ordner 3 hat keine weiteren Unterordner und erhält auf beiden Laufwerken jeweils rund 400.000 Bilder (die genaue Ausgabe für

Code: [Auswählen]

find . -type f | wc -l
stimmt überein).

+ Dagegen stimmt die Ausgabe für

find . -type f \( -exec sha1sum "{}" \; \) | sort -k2,2 | sha1sum

nicht überein. -

Was kann ich nun noch probieren?

[anno_2020]

Ich habe jetzt noch mal die Dateien und Verzeichnisse überprüft, bei denen es bisher Übereinstimmung gab. Bei den meisten besteht - wie zu erwarten - die Übereinstimmung weiterhin.

Aber bei dieser Datei:

1. Ich hatte gestern Abend die (größte) .zip-Datei in meinem Verzeichnis 2 ein weiteres Mal gelöscht und dann erneut grsycnt.

2. Zumindest der SHA256-Wert für diese Datei stimmt nun auf Quell- und Ziel-Laufwerk überein.

wurden mir jetzt bei zwei aufeinander folgenden Versuchen auf dem Ziel-Laufwerk zwei unterschiedliche - aber beide Male: falsche - Werte ausgegeben. -

In meinem Terminal wird mir noch der ganze Verlauf von heute angezeigt, sodass ich auch die Ausgabe von heute Vormittag überprüfen konnte - und in der Tat wurde mir heute Vormittag der korrekte Wert ausgegeben. Und ich habe seitdem auch keine erneuten Löschungen und Synchronisierungen vorgenommen. -

Wie kann es sein, dass nun trotzdem wieder falsche Werte ausgegeben werden (und noch dazu unterschiedliche)?!

PS.:

Dritter Durchlauf - dritter (falscher) Wert für ein- und dieselbe Datei auf ein- und demselben Laufwerk.

Ich bin in dem Verzeichnis, wo die Datei liegt; Eingabe ist

Code: [Auswählen]

sha256sum -b DATEINAME

PPS.:

Für den Bilderordner im Ziel-Laufwerk habe ich jetzt noch mal

Code: [Auswählen]

find . -type f \( -exec sha1sum "{}" \; \) | sort -k2,2 | sha1sum
eingegeben; auch dafür ist die Ausgabe jetzt anders als beim ersten Durchlauf, aber weiterhin nicht mit dem Quell-Laufwerk übereinstimmend.

[Whitie]

Was ist das für eine Datei, die nicht stimmt (Dateityp)?

Ich würde:

Code: [Auswählen]

$ cd Quelle
$ find . -type f \( -exec sha1sum "{}" \; \) | sort -k2,2 > /home/$USER/Quelle.txt
$ cd Ziel
$ find . -type f \( -exec sha1sum "{}" \; \) | sort -k2,2 > /home/$USER/Ziel.txt
$ cd ~
$ vimdiff Quelle.txt Ziel.txtdas probieren.

Gruß
Whitie

[anno_2020]

Guten Morgen und vielen Dank.

Ich hatte jetzt das Ziel-Laufwerk ausgeworfen, ab- und wieder angestöpselt; nun stimmt der SHA1-Wert für den Bilder-Ordner. - Wie kann das sein, dass dies Abhilfe bietet, und was kann gestern Fehlergrund gewesen sein?

Zu der einzelnen Datei kam ich heute noch nicht erneut; es ist eine .zip-Datei (belegt fast 40 % der 250 GB-Ziel-SSH). -

Ich frage jetzt erst noch mal den SHA256-Wert für die .zip-Datei ab und sehe mir währenddessen die neuen Befehle an.

[anno_2020]

Den SHA256-Wert für die .zip-Datei habe ich jetzt auch noch zweimal abgefragt; zwischendurch ein weiteres mal an- und abgestöpselt: Beides mal ein falscher Wert - beides Male unterschiedliche Werte.

[anno_2020]

Ich habe jetzt - sicherheitshalber und um's auszuprobieren - den Code von Antwort # 35 für mein Bilder-Verzeichnis ausprobiert.

Obwohl heute morgen schließlich übereinstimmende SHA1-Werte für den gesamten Ordner ausgegeben wurde, findet vimdiff (vim musste ich mit

Code: [Auswählen]

sudo apt-get install vim
erst installieren) drei unterschiedliche Dateien:

Was muss ich denn im Terminal eingeben, um die Bilddatei direkt aus dem Terminal z.B. mit Pix zu öffnen (mein Dateimanager bzw. Arbeitsspeicher scheint mit riesengroßen Verzeichnis des fraglichen Ordners überfordert zu sein)?

[MAlfare]

Eine Möglichkeit, dass Zieldatei und Quelldatei nicht identisch sind, ist das RAM.
Habe das vor langer Zeit einmal auf einem Novell Netware Server erlebt.
Da die Daten beim Kopieren und auch beim Erstellen der Hashes durch den Speicher müssen, wäre das eine Möglichkeit.

[tam]

Was muss ich denn im Terminal eingeben, um die Bilddatei direkt aus dem Terminal z.B. mit Pix zu öffnen

Am besten mit "cd" ins Verzeichnis wechseln und "pix Dateiname" eingeben. Wenn du an den Schluß noch ein "&" anhängst wird der Prozeß in den Hintergrund geschickt und das Terminal ist gleich wieder verfügbar.
Evtl, wenn du sehr viele Bilder hast, pix erst mal ohne Datei aufrufen und Vorschau auschalten.
[MOD: fehlerhafte Zitat-Quelle entfernt.]

[toffifee]

Aber vor dem & ein Leerzeichen!

[tam]

Aber vor dem & ein Leerzeichen!

Muss das wirklich sein? (Ernst gemeinte Frage.)