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

[anno_2020]

1. Ich habe zwei Ordner von einer externen Festplatte zu einer anderen externen Festplatte kopiert.

2. Nach verschiedenen anderen Versuchen habe ich es schließlich in der Weise gemacht, dass ich die beiden Ordner auf der Ziel-Festplatte noch einmal löschte und dann - für jeden der beiden Ordner separat - eine Synchronisation mittels Grsync vornahm. Beide Prozesse endeten mit "Erfolgreich abgeschlossen." (https://www.linuxmintusers.de/index.php?topic=64470.msg846168#msg846168 ["PS.:"] und https://www.linuxmintusers.de/index.php?topic=64470.msg846225#msg846225)

3. Während der SHA-Wert für Ordner 1 auf beiden Laufwerken identisch ist, ist er für Ordner 2 auf beiden Laufwerken unterschiedlich.

4. Für den zweiten Ordner habe ich jetzt im Terminal noch einmal

Code: [Auswählen]

rsync --dry-run -v -r -t -l --delete /media/MEIN_BENUTZERNAME/'TOSHIBA EXT'/ORDNER/UNTERORDNER_1/ /media/MEIN_BENUTZERNAME/NAME_DER_FESTPLATTE/ORDNER_1/
eingeben.

Als Antwort kam diesmal (schnell):

sending incremental file list

Dann ziemlich lange nichts (diesmal auch keine Auflistung von Dateien); und schließlich dies:

sent 29,188,985 bytes  received 436,584 bytes  9,019.81 bytes/sec
total size is 197,456,680,704  speedup is 6,665.08 (DRY RUN)

Bleibt die Frage:

Lässt sich das Problem der unterschiedlichen SHA-Werte zielgerichtet beheben? Oder bleibt nichts anderes übrig, als sich entweder in die Ungewissheit, ob das Kopieren korrekt geklappt hat, zu fügen oder aber das Löschen und Syncen solange zu wiederholen, bis irgendwann auch die SHA-Werte für Ordner 2 überstimmen?

[anno_2020]

Ich habe jetzt noch folgendes überprüft:

+ In dem fraglichen Ordner liegen fünf Dateien und drei Unterordner.

+ Für die fünf Dateien habe ich nun noch die SHA256-Werte abgefragt. Für die größte dieser Dateien sind die Werte auf beiden Laufwerk unterschiedlich.

+ Ich habe die Datei also ein weiteres Mal gelöscht und Grsync erneut gestartet - mal sehen...

[anno_2020]

Grsync ist ohne Fehlermeldung durchgelaufen; der SHA256-Wert für die fragliche Datei ist auf beiden Laufwerken weiterhin unterschiedlich...

[anno_2020]

Ich habe die Datei ein weiteres mal gelöscht und nun - zur Abwechselung noch mal mit "cp" im Terminal - kopiert. Weiterhin der falsche SHA256-Wert... - Woran kann das denn liegen? -

(Einmal war es mir schon gelungen, zumindest diese Datei mit dem korrekten SHA256-Wert zu kopieren (*); aber der SHA1-Wert für den ganzen Ordner stimmte nicht.)

(*) https://www.linuxmintusers.de/index.php?topic=64470.msg845912#msg845912

[tam]

(Einmal war es mir schon gelungen, zumindest diese Datei mit dem korrekten SHA256-Wert zu kopieren (*); aber der SHA1-Wert für den ganzen Ordner stimmte nicht.)

Du kannst nur für Dateien einen SHA-Wert ermitteln, nicht für Ordner.

[anno_2020]

Das ist ja eine .zip-Datei (in einem Ordner, in dem weiteren Dateien und Unterordner sind).

PS.:

Ob der SHA256-Wert für Ordner nicht ermittelt werden kann, weiß ich nicht (wenn du es sagst, wird es stimmen); aber dies:

Code: [Auswählen]

cd /some/dir
find . -type f \( -exec sha1sum "{}" \; \) | sort -k2,2 | sha1sum
https://unix.stackexchange.com/questions/106275/du-gives-two-different-results-for-the-same-file

scheinen doch die Befehle zum Ermitteln des SHA1-Wertes des jeweiligen Verzeichnis zu sein, oder nicht?

[aexe]

Also ich verstehe den Code zwar nicht, habe aber trotzdem Zweifel, dass er funktioniert:

Code: [Auswählen]

user@T-LM20:~$ cd bin
user@T-LM20:~/bin$ find . -type f \( -exec sha1sum "{}" \; \) | sort -k2,2 | sha1sum
… Mein Rechner ist nicht sehr langsam, aber das Ergebnis lässt seit gut 15 min auf sich warten.

Inhalt des Verzeichnis:

Code: [Auswählen]

user@T-LM20:~/bin$ ls
Block-Bluetooth.sh            MTPlayer        touchscreen-off
chromium-latest-linux-master  start-conky.sh  TVPlayer3 (3.747 Objekte, mit insgesamt 725,6 MB)
Ist zwar nicht gerade wenig, aber 15 min sollten doch für eine sha1 reichen?

[anno_2020]

Der Code funktioniert bei mir; und für mein Verzeichnis 1 werden auf beiden Laufwerken auch übereinstimmende Werte ausgegeben. Aber in der Tat dauert die Berechnung bei großen Verzeichnissen eine ganze Weile.

Mein Problem ist, dass die beiden Werte (auf Quell- und Ziel-Laufwerk) für mein Verzeichnis 2 nicht übereinstimmen.

[MAlfare]

Also ich verstehe den Code zwar nicht, habe aber trotzdem Zweifel, dass er funktioniert:
Ist zwar nicht gerade wenig, aber 15 min sollten doch für eine sha1 reichen?

Scheint so
Sieht für mich aus, als werde für jede Datei ein sha1 erzeugt, diese dann sortiert und  daraus ein sha1 erzeugt.
Also nicht "eine" sondern 3.748.

[Whitie]

Hallo,
also auf diese Weise einen Hashwert für ein Verzeichnis zu generieren halte ich für problematisch. Die einzelnen Dateien müssen übereinstimmen, das zählt.
Probleme:
1. Im Quellverzeichnis könnte z. B. noch eine versteckte Datei sein, die nicht mitkopiert wird -> Hash stimmt nicht mehr
2. Der find Befehl gibt dir den Hash und den Pfad der Datei aus. Die Pfade müssen also in Quelle und Ziel komplett gleich sein. Probier einfach mal den Befehl ohne die Pipe's aus und vergleiche (nimm ein Verzeichnis mit wenig Dateien).

Gruß
Whitie

[ZeckeSZ]

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

Kann m.E. zu 99,9% ausgeschlossen werden, da rsync ohne Fehlermeldung durchläuft. Die Inhalte der Verzeichnisse werden somit, geprüft auf Änderungsdatum und Größe der einzelnen Dateien, völlig identisch sein.

Wenn aber der Ausgabe von rsync misstraut wird, dann mein Tipp: Jede Datei einzeln auf eine eventuelle Veränderung überprüfen. Viel Spaß dabei...

[anno_2020]

Zwischenstand:

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.

3. Für die anderen vier Dateien in dem Ordner hatten sich die SHA256-Werte ja gestern schon als übereinstimmend erwiesen (siehe Antwort # 2: "Für die fünf Dateien habe ich nun noch die SHA256-Werte abgefragt. Für die größte dieser Dateien sind die Werte auf beiden Laufwerk unterschiedlich.")

4. Außerdem sind in meinen Verzeichnis 2 drei Unterordner. Von diesen habe ich bisher den kleinsten (2,1 GB; aber fast 100.000 Objekte) abglichen. SHA1-Werte sind übereinstimmend.

Ist zwar nicht gerade wenig, aber 15 min sollten doch für eine sha1 reichen?

Die Berechnung für meinen 2,1 GB-Unterordner hat ca. eine halbe Stunde gedauert (core i7 4600U CPU @ 2,1 GHz x 2; 7,7 GiB RAM).
(Nachtrag: Berechnungsdauer allein für das Ziel-Laufwerk; für das Quell-Laufwerk hatte ich den Wert eh zur Hand.)

5. Nun also noch die letzten beiden Unterordner und dann - sicherheitshalber - noch mal das ganze Verzeichnis 2.

-

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.

[ZeckeSZ]

Was sind denn Pipes überhaupt?

Du zweifelst die Ausgabe von rsync an, hast aber keine Ahnung von dem, was der Befehl, den du von irgendwo aus dem Internet heraus kopiert hast, genau bewirkt und wo bei diesem eventuell Fallstricke zu erwarten wären.

Bevor du also weitere Fragen diesbezüglich stellst, solltest du dir vielleicht erst einmal ein paar Grundlagen die Terminalbefehle betreffend anlesen. Oder du verwendest Programme, deren Bedienung und Ausgabe du verstehst. Wie der Inhalt eines Verzeichnisses auch zu vergleichen ist, wurde dir in einem anderen Thread ja bereits mitgeteilt.

Ich zumindest bin hier jetzt raus.

[anno_2020]

was der Befehl, den du von irgendwo aus dem Internet heraus kopiert hast

Den habe ich daher, wo du mich hingeschickt hattest:

https://unix.stackexchange.com/questions/106275/du-gives-two-different-results-for-the-same-file

[ZeckeSZ]

Den habe ich daher, wo du mich hingeschickt hattest

Asche auf mein Haupt...
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.

Links mit solchen Befehlen werde ich in Zukunft wohl nicht mehr posten, ich weiß ja jetzt, was dabei rauskommen kann...