[Lookbehind]

Hallo zusammen,

ich hab hier zwei recht große Verzeichnisse (groß im Sinne von ~50.000 Dateien, nicht im Sinne von Speicherplatz) mit mehreren verschachtelten Unterverzeichnissen und einem riesen Haufen an Binär-Dateien. Diese beiden Verzeichnisse waren vor gefühlten Jahrtausenden mal identisch und sollen es jetzt wieder werden. In der Zwischenzeit sind in beiden Verzeichnissen Dateien geändert worden, verschoben worden, gelöscht worden und hinzugekommen.

Leider liegt dem ganzen keine Versionsverwaltung zugrunde. Dann wärs nämlich einfach

Ich suche also eine Lösung, wie ich die beiden Verzeichnisse sinnvoll wieder zusammen führen kann. Ganz ohne Handarbeit wird das nicht gehen. Aber zumindest ein wenig automatisierte Hilfe könnte nicht schaden.

Meine Idee wäre folgendes:
Ich bilde über beide Verzeichnisse die sha1-summe aller Dateien. und speichere sie, samt Dateipfad in einer Datei.
Anschließend bilde ich daraus Schnittmengen.
Eine Liste mit allen Dateien bei denen Hash und Dateipfad in beiden Verzeichnissen übereinstimmen.
Eine Liste mit allen Dateien die in einem der beiden Verzeichnisse doppelt vorkommen. (i.e. mehrmals der gleiche Hash im gleichen Verzeichnis)
Eine Liste mit allen Dateien bei denen der Hash aber nicht der Dateipfad in den beiden Verzeichnissen übereinstimmt.
Eine Liste mit allen Dateien bei denen der Dateipfad aber nicht der Hash in beiden Verzeichnissen übereinstimmt.
Eine Liste mit allen Dateien die nur in jeweils einem der beiden Verzeichnisse vorkommen.
... Hab bestimmt was vergessen.
Das ganze würde ich, aus Geschwindigkeitsgründen (Entwicklungs und Ausführungsgeschwindigkeit) in Python gießen.
Das Zusammenführen würd ich dann von Hand machen. Da das Binärdateien sind, lässt sich der Inhalt leider schlecht automatisiert vergleichen. ... theoretisch wäres machbar, weil fast alle das gleiche Format ... aber dann müsst ich erst nen Parser und ... naaaa!

Bevor ich da aber Entwicklungsarbeit investiere wollt ich lieber mal nachfragen, ob es da nix von Ratiopharm gibt? Ich muss das Rad ja nicht immer neu erfinden.
Ich würde Lösungen die auf Linux (GUI oder Shell soll mir egal sein) laufen bevorzugen, kann aber auch mit Windows aufwarten, wenn es dann einfacher wird.


TIA

Look

[foobar]

Bin mir nicht sicher, ob der Ansatz mit den Hashes großartig Sinn macht. Damit weißt du, dass zwei Dateien mit gleichem Namen einen unterschiedlichen Inhalt haben, aber nicht, welche von den beiden du nun nehmen sollst. In der Regel will man ja, dass die neuere der beiden Dateien gewinnt. Nehme ich jedenfalls an. Also würde ich mich an den Zeitstempeln orientieren, nicht an den Hashes.

Wenn du es zu Fuß machen willst, würde ich also ein Skript schreiben, das rekursiv durch alle Dateien in Verzeichnis A geht (quasi 'find -type f') und dann guckt, ob eine Datei diesen Namens in Verzeichnis B existiert. Falls nein, kopiere die Datei nach C (dem zusammengeführten Ordner). Falls ja, kopiere die A-Datei nur, wenn sie neuer ist ('test -nt' oder 'stat' parsen). Ansonsten ignoriere die Datei. Lässt du das Skript nacheinander auf A und B los, sollte in C schonmal alles da sein. Dateien gleichen Inhalts, die umbenannt wurden und deshalb doppelt in C liegen, kann man nachträglich mit 'duff' oder etwas ähnlichen beseitigen. Damit müsstest du in C nun deine aufgeräumte Pornosammlung vorfinden.

Eine fertige Alternative wäre ein doppeltes rsync mit dem Updateflag ('-u') von A nach B und nochmal von B nach A. Und dann muss man nochmal die Duplikate beseitigen. Siehe 'duff'.

Wenn du nicht automatisch die neuste Version einer Datei selektieren willst oder auf die Zeitstempel kein Verlass ist (schlechtes Dateisystem oder so) oder du einfach mehr manuelle Kontrolle willst, dann bist du vermutlich mit dem Unison File Synchronizer besser bedient. Der gleicht automatisch in beide Richtungen ab, wenn es keine Konflikte gibt. Und bei Konflikten wirst du halt gefragt, was passieren soll. Keine eigenen Erfahrungen, caveat emptor.

[Lookbehind]

Nette Idee, aber der Zeitstempel wird mir nicht helfen. Nicht weil das Dateisystem schlecht wäre (ext4) sondern einfach, weil die Änderungen durchaus unterschiedlich sein können und nicht zeitlich abhängig sind. Kurz: "neuer" ist nicht zwangsweise "besser". Ich werde also nicht umhin kommen, mir die Konflikte händisch an zu schauen. Ich hoffe einfach nur, dass das nicht zu viele werden.

Zu Unison kann ich aber ein paar Worte sagen. Das benutz ich nämlich schon seit fast 10 Jahren beinahe täglich um z.B. meinen Laptop und meinen Desktop zu synchronisieren. Für solche Anwendungsgebiete funktioniert das auch super! Kanns nur empfehlen.
Allerdings setzt Unison voraus, dass beide kopien bei der allerersten Synchronisierung identisch sind. Danach werden dann Änderungen synchronisiert. Das würde hier aber nicht helfen. Selbst wenn ich auf den Trick zurück greife zuerst 2 leere Ordner zu synchronisieren und dann auf beiden Enden alles ein zu fügen. In dem Fall wäre für Unison dann einfach auf beiden Seiten alles neu. Da kann ich dann auch einfach beide Verzeichnisse zusammen kopieren.

Um das noch kurz klar zu stellen: Es geht mir nicht darum einfach unbedingt alles zusammen zu haben. Sondern eine gewisse Sortierung zu behalten. Wenn z.B. eine Datei in beiden Verzeichnissen unter anderem Namen liegt, dann kann es durchaus sein, dass da mal jemand einen Tippfehler im Dateinamen beseitigt hat. Da möchte ich natürlich die korrigierte Version behalten. Letztlich sind das alles menschenlesbare Dateinamen. Leider gab es da über mehrere Jahre an zwei Enden ziemlichen Wildwuchs.

[foobar]

Hmm... ok, dann kann ich dir nur noch ein paar Open Source Programme nennen, die recht mächtige Synchronisationsoptionen haben. Ob die geeignet sind, musst du aber selbst prüfen.

https://freefilesync.org/
https://syncthing.net/
https://owncloud.org/

Die sollen angeblich alle imstande sein, Konflikte zu erkennen, Revisionskontrolle durchzuführen sowie gelöschte und umbenannte Dateien zu erkennen. Nextcloud ginge theoretisch auch, aber da gibt's wohl einen Bug bei den gelöschten Dateien. Wenn das nicht so dramatisch ist, kannst du dir auch das angucken.

[Lookbehind]

Hihi, Funfact: Nachdem da einmal ein bisschen Ordnung rein gebracht wurde, soll das ganze in eine NextCloud gelegt werden, damit demnächst alle auf dem gleichen Datensatz arbeiten können, und da nicht wieder zwei Parallel-Universen entstehen.

Mir geht es auch weniger darum die Dateien wirklich zu kopieren/verschieben. Da hat so ein Linux schon ein paar mächtige Werkzeuge für. Vielmehr geht es darum die Dubletten zu finden, die umbenannten, die veränderten. Quasi nachträglich eine Art Änderungshistorie zu bekommen. Dass die nicht so detailliert wird wie ein Git-Repo ist mir auch klar. (Leider werde ich den Leuten nicht den Umgang mit Git beibringen können. Das wäre langfristig DIE Lösung.)

[foobar]

Vielmehr geht es darum die Dubletten zu finden, die umbenannten, die veränderten.

Eventuell hilft dir auch hier 'duff'. Es spürt halt Dubletten auf. Löschen ist, wie bei Unix üblich, der Job eines anderen Tools. Man kann einstellen, welcher Hashalgorithmus verwendet werden soll, eine Größe festlegen, ab der es erstmal nur die ersten paar Bytes vergleicht, bevor es den vollen Hash berechnet (Optimierung für große Dateien), rekursiv arbeiten und wenn man will, sogar byteweise vergleichen (falls man dem Hash als Merkmal für Gleichheit nicht vertraut).

An irgendeinem Punkt wird es letztlich für jedes Programm schwierig, einen Zusammenhang zwischen zwei Dateien zu finden. Wenn eine Datei anders heißt und einen anderen Inhalt hat, wird dir vermutlich kein Programm der Welt sagen können, dass das "eigentlich" die gleiche Datei ist, die nur zwischenzeitlich geändert und umbenannt wurde. Eventuell kann man versuchen, mit xdelta oder ähnlichen Geschichten zu schauen, wie ähnlich zwei Dateien sind und diese Metrik dann nehmen, um alles unter einem bestimmten Schwellwert als potentielle Kandidaten aufzulisten. Aber das wird kompliziert und trotzdem nicht zuverlässig alles finden. Sowas wird man wohl manuell machen müssen. Da hilft auch keine Liste mit Hashes.

[Lookbehind]

Och, das geht auch mit hash-Listen ganz gut. Nach ein paar anfänglichen Experimenten hat sich meine Befürchtung, dass sich die weitere Verarbeitung auf Grund der Menge an Daten recht lange hin ziehen würde, nicht bestätigt. Selbst die etwas komplexeren Shell-Kommandos sind quasi instant fertig. Weshalb ich mich dann doch entschieden habe, das ganze in der Shell zu erschlagen, statt Python dafür zu bemühen. ... ich staune ja immer wieder was man mit ein wenig RegExp und etwas Shell-Magie (aka sed, grep, sort, uniqe, for und der Verwendung von Pipes) alles hin bekommt.

Wie man so merkt wird auch nicht alles so heiß gegessen wie es gekocht wird. Von 41609 Dateien sind 41441 nicht nur binär identisch, sondern haben auch in beiden Ordnern den gleichen Unterpfad und Dateinamen. Die Summe der Dateien die ich mir also angucken muss ist noch recht überschaubar. Ich hatte da mit mittleren vierstelligen Werten gerechnet.