Beitrag von: anno_2020 am 08.10.2020, 13:32:17
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):
Zitat
sending incremental file list
Dann ziemlich lange nichts (diesmal auch keine Auflistung von Dateien); und schließlich dies:
Zitat
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?
Beitrag von: anno_2020 am 08.10.2020, 16:35:21
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...
Beitrag von: anno_2020 am 08.10.2020, 18:32:34
Grsync ist ohne Fehlermeldung durchgelaufen; der SHA256-Wert für die fragliche Datei ist auf beiden Laufwerken weiterhin unterschiedlich...
Beitrag von: anno_2020 am 08.10.2020, 19:27:22
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
Beitrag von: tam am 08.10.2020, 19:54:49
(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.
Beitrag von: anno_2020 am 08.10.2020, 19:56:26
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 | sha1sumhttps://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?
Beitrag von: aexe am 08.10.2020, 21:03:58
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?
Beitrag von: anno_2020 am 08.10.2020, 21:09:17
Mein Problem ist, dass die beiden Werte (auf Quell- und Ziel-Laufwerk) für mein Verzeichnis 2 nicht übereinstimmen.
Beitrag von: MAlfare am 08.10.2020, 22:43:55
Also ich verstehe den Code zwar nicht, habe aber trotzdem Zweifel, dass er funktioniert:Scheint so ;D
Ist zwar nicht gerade wenig, aber 15 min sollten doch für eine sha1 reichen?
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.
Beitrag von: Whitie am 09.10.2020, 07:31:41
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
Beitrag von: ZeckeSZ am 09.10.2020, 10:18:34
Im Quellverzeichnis könnte z. B. noch eine versteckte Datei sein, die nicht mitkopiert wirdKann 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...
Beitrag von: anno_2020 am 09.10.2020, 10:29:13
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?
Zitat
Probier einfach mal den Befehl ohne die Pipe's aus und vergleiche
Was sind denn Pipes überhaupt?
Zitat
(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.
Beitrag von: ZeckeSZ am 09.10.2020, 11:07:18
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.
Beitrag von: anno_2020 am 09.10.2020, 11:09:35
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 (https://unix.stackexchange.com/questions/106275/du-gives-two-different-results-for-the-same-file)
Beitrag von: ZeckeSZ am 09.10.2020, 11:22:30
Den habe ich daher, wo du mich hingeschickt hattestAsche 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...
Beitrag von: anno_2020 am 09.10.2020, 11:31:25
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.
Beitrag von: Whitie am 09.10.2020, 13:23:22
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?ZitatProbier einfach mal den Befehl ohne die Pipe's aus und vergleiche
Was sind denn Pipes überhaupt?Zitat(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
Beitrag von: anno_2020 am 09.10.2020, 16:12:52
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. :o
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 | sha1sumWird ein Weilchen dauern; melde mich dann später noch mal.
Beitrag von: anno_2020 am 09.10.2020, 18:02:16
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.
Beitrag von: anno_2020 am 09.10.2020, 18:25:38
+ 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.
Beitrag von: anno_2020 am 09.10.2020, 20:19:32
+ 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 -lstimmt überein).
+ Dagegen stimmt die Ausgabe für
Zitat
find . -type f \( -exec sha1sum "{}" \; \) | sort -k2,2 | sha1sum
nicht überein. -
Was kann ich nun noch probieren?
Beitrag von: anno_2020 am 09.10.2020, 22:25:55
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 DATEINAMEPPS.:
Für den Bilderordner im Ziel-Laufwerk habe ich jetzt noch mal
Code: [Auswählen]
find . -type f \( -exec sha1sum "{}" \; \) | sort -k2,2 | sha1sumeingegeben; auch dafür ist die Ausgabe jetzt anders als beim ersten Durchlauf, aber weiterhin nicht mit dem Quell-Laufwerk übereinstimmend.
Beitrag von: Whitie am 10.10.2020, 08:44:05
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
Beitrag von: anno_2020 am 10.10.2020, 08:56:45
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.
Beitrag von: anno_2020 am 10.10.2020, 09:55:50
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.
Beitrag von: anno_2020 am 10.10.2020, 14:25:09
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 vimerst 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)?
Beitrag von: MAlfare am 10.10.2020, 15:44:09
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.
Beitrag von: tam am 10.10.2020, 18:56:56
Zitat
Was muss ich denn im Terminal eingeben, um die Bilddatei direkt aus dem Terminal z.B. mit Pix zu öffnenAm 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.]
Beitrag von: toffifee am 10.10.2020, 19:04:49
Beitrag von: tam am 10.10.2020, 19:41:36
Aber vor dem & ein Leerzeichen!Muss das wirklich sein? (Ernst gemeinte Frage.)
Beitrag von: anno_2020 am 10.10.2020, 20:08:37
Vielen Dank. -
Quell-Laufwerk:
Zitat
pix /media/MEIN_BENUTZERNAME/TOSHIBA EXT/VERZEICHNIS/VERZEICHNIS/VERZEICHNIS/VERZEICHNIS/VERZEICHNIS/NAME.jpg &
Code: [Auswählen]
[1] 2907411Pix zeigt ausschließlich eine weiße Seite mit "(leer)".
Ziel-Laufwerk:
Code: [Auswählen]
pix /media/MEIN_BENUTZERNAME/FESTPLATTEN-NAME/VERZEICHNIS/VERZEICHNIS/VERZEICHNIS/VERZEICHNIS/NAME.jpg &Code: [Auswählen]
[2] 2907418
[1] Fertig pix /media/MEIN_BENUTZERNAME/FESTPLATTEN-NAME/VERZEICHNIS/VERZEICHNIS/VERZEICHNIS/VERZEICHNIS/NAME.jpgPix zeigt am linken Rand auf weißem Hintergrund "(leer)" an - und im Hauptbereich das Bild. -
Das ist ja nun erst recht überraschend, oder? - Wäre nicht wenn, damit zu rechnen, dass die Anzeige der Datei des Ziel-Laufwerks nicht funktioniert (zumal die Ziel-Festplatte jedenfalls die stärker benutzte und vermutlich auch ältere ist).
PS.:
Ja, mein Ziel-Laufwerk hat eine Verzeichnisebene weniger als das Quell-Laufwerk.
Beitrag von: ZeckeSZ am 11.10.2020, 10:57:08
Off-Topic:Muss das wirklich sein?Ich denke schon.
pix /media/MEIN_BENUTZERNAME/TOSHIBA EXT/VERZEICHNIS/VERZEICHNIS/VERZEICHNIS/VERZEICHNIS/VERZEICHNIS/NAME.jpg &Kann nicht funktionieren, aber das hatten wir ja schon mal: https://www.linuxmintusers.de/index.php?topic=64452.msg845386#msg845386 (https://www.linuxmintusers.de/index.php?topic=64452.msg845386#msg845386)
Beitrag von: anno_2020 am 11.10.2020, 11:01:44
Jetzt ist mir folgendes noch aufgefallen: Ich muss bei meinem Quell-Laufwerk auch hier wieder TOSHIBA EXT in einfache Anführungszeichen setzen.
Wenn ich das mache, dann kann ich alle drei von VIMDIFF genannten Dateien - sowohl auf Quell- als auch Ziel-Laufwerk - öffnen, und ich kann auf den Bildern keine Unterschiede / Fehler o.ä. entdecken. -
Soll ich dann vllt. diese drei Dateien noch mal zielgerichtet kopieren und anschließend das Procedere mit den .txt-Dateien und VIMDIFF erneut machen?
Beitrag von: anno_2020 am 11.10.2020, 11:02:43
Kann nicht funktionieren, aber das hatten wir ja schon mal:
Ja, inzwischen habe ich es auch bemerkt.
Beitrag von: anno_2020 am 11.10.2020, 21:00:12
@ Antwort #32:
Ich habe das inzwischen gemacht - und die VIMDIFF-Abfrage diesmal für mein ganzes Verzeichnis 2:
VIMDIFF hat wiederum Unterschiede gefunden:
+ Auch erneut in meinem Bilder-Ordner - aber andere als zuvor.
+ und auch in anderen Ordnern und bei der großen zip-Datei.
Genauer sehe ich mir das morgen an.
Beitrag von: Whitie am 12.10.2020, 13:15:10
Aber Vorsicht, ist natürlich längst nicht so effizient wie Tools, die auf Kopieren spezialisiert sind. Dauert also lange.
Runterladen und Endung wieder in .py ändern (.txt einfach löschen). Irgendwo hinlegen (z. B. ~/bin) und dann python3 /Pfad/zum/Skriptordner/filecopy.py -h aufrufen. Der Rest (Optionen des Skriptes) sollte selbsterklärend sein.
Gruß
Whitie
Beitrag von: anno_2020 am 17.10.2020, 11:41:10
Wegen
Dauert also lange.
und der ungewissen Aussicht wie wie stark das meinen Lüfter in Anspruch nimmt, hatte ich mir das für's Wochenende aufgespart.
Jetzt habe ich es probiert. Ich musste erst einmal Python installieren. Danach kam nun auf (ich habe die Datei einfach im Download-Ordner liegen lassen):
<code>python /home/MEIN_BENUTZERNAME/Downloads/filecopy.py -h</code>
diese Fehlermeldung:
<quote>File "/home/MEIN_BENUTERNAME/Downloads/filecopy.py", line 65
print(f'Quellverzeichnis ({source}) wird bearbeitet')
^
SyntaxError: invalid syntax</quote>
Beitrag von: MAlfare am 17.10.2020, 12:03:25
Kann kein Python, aber sollte wohl heißen:Code: [Auswählen]File "/home/MEIN_BENUTERNAME/Downloads/filecopy.py", line 65
print(f'Quellverzeichnis ({source}) wird bearbeitet')
^
SyntaxError: invalid syntax
Code: [Auswählen]
printf('Quellverzeichnis ({source}) wird bearbeitet')also ein einfacher "Zahlendreher"
Beitrag von: anno_2020 am 17.10.2020, 12:18:53
Das habe ich in der Datei geändert; dann kam die entsprechende Fehlermeldung für die Zeile
Code: [Auswählen]
print(f'{len(files)} Dateien gefunden, berechne Hashes')Auch dort habe ich dann die Reihenfolge der öffnende Klammer und des f umgedreht. Nächster Versuch:
Zitat
File "/home/MEIN_BENUTZERNAME/Downloads/filecopy.py", line 70
print('.', end='', flush=True)
^
SyntaxError: invalid syntax
Beitrag von: Whitie am 17.10.2020, 13:49:07
Das Skript läuft bei mir ohne Probleme (sonst hätte ich es nicht gepostet).
Würde fast vermuten, du versuchst das mit Python 2 auszuführen.
Gruß
Whitie
Beitrag von: {°-°} am 17.10.2020, 14:08:09
Kann kein Python, aber sollte wohl heißen:printf gibt es in Shell-Skripts, aber python kennt es nicht ootb – auch nicht in den verwendeten Modulen.Code: [Auswählen]printf('Quellverzeichnis ({source}) wird bearbeitet')
Das habe ich in der Datei geändert;Bitte rückgängig machen.
Beitrag von: anno_2020 am 17.10.2020, 14:19:23
Danke.
Ich habe die Datei erneut runtergeladen und die Endung verkürzt.
@:
Zitat
Würde fast vermuten, du versuchst das mit Python 2 auszuführen.
Ja, scheint so. Ich hatte:
Code: [Auswählen]
sudo apt-get install pythoneingebenen; als Antwort kam unter anderem:
Zitat
Hinweis: »python-is-python2« wird an Stelle von »python« gewählt.
Zitat
python-is-python2 (2.7.17-4) wird eingerichtet
Was muss ich für Python 3.6 eingeben?
Beitrag von: Whitie am 18.10.2020, 07:53:52
Ich habe hier LM 20 XFCE, da war Python 3.8 bereits drauf nach der Installation. Probier doch einfach mal:
Code: [Auswählen]
$ python3 filecopy.py -hIch denke Python 3 sollte bereits da sein, da LM das auch selber verwendet.
Gruß
Whitie