[gelöst] gnu-find und gnu-diff

hat sich gut eingelebt.

Architektur: 32-bit

Dienstag, 3. Juli 2007, 11:42

gnu-find und gnu-diff

Hallo Leute,

ich würde gern kontrollieren, ob ein Backup meines HOME-Verzeichnisses
mit dem Original übereinstimmt.

Dazu habe ich mit "find" im HOME-Verzeichnis alle Dateien in eine Datei1 geschrieben.

	Quellcode
1	find . -name '*' -fprint Datei1.txt

Dann bin ich in das Backup-Verzeichnis gegangen und habe dort die Dateien in Datei2 geschrieben.

	Quellcode
1 2	cd /backup find . -name '*' -fprint Datei2.txt

Schlussentlich habe ich beide Dateien mit "diff" verglichen.

	Quellcode
1	diff -y Datei1.txt Datei2.txt > Differenz.txt

Leider war das Ergebnis nicht so, wie ich mir das vorgestellt hatte.

Obwohl das Backup mit "rsync" erfolgte, stehen die einzelnen Dateien des Home-Verzeichnis
in der Datei1.txt an anderer Stelle, als die Dateien des Backups in der Datei2.txt.
Das führt dazu, dass "diff" mir alle Dateien auflistet, und nicht nur die Fehlenden!

Wie geht es richtig?
Ich denke es muss gehen, weil ich vorher in Foren, Wikis und HOWTOS
gelesen habe, dass ein Backup nur dann gut ist, wenn ein Vergleich OK ist.

Ich poste mal einen Teil der Differenz.txt.

Quellcode

.
.
.

							  	>	./.evolution/secmod.db
./.gconf							./.gconf
./.gconf/desktop					  	|	./.gconf/GNOME
./.gconf/desktop/gnome					  	|	./.gconf/GNOME/Spell
./.gconf/desktop/gnome/accessibility			  	|	./.gconf/GNOME/Spell/%gconf.xml
./.gconf/desktop/gnome/accessibility/keyboard		  	|	./.gconf/GNOME/%gconf.xml
./.gconf/desktop/gnome/accessibility/keyboard/%gconf.xml  	<
./.gconf/desktop/gnome/accessibility/%gconf.xml		  	<
./.gconf/desktop/gnome/%gconf.xml			  	<
./.gconf/desktop/gnome/peripherals			  	<
./.gconf/desktop/gnome/peripherals/keyboard		  	<
./.gconf/desktop/gnome/peripherals/keyboard/host-mars	  	<
./.gconf/desktop/gnome/peripherals/keyboard/host-mars/0	  	<
./.gconf/desktop/gnome/peripherals/keyboard/host-mars/0/%gcon <
./.gconf/desktop/gnome/peripherals/keyboard/host-mars/%gconf. <
./.gconf/desktop/gnome/peripherals/keyboard/%gconf.xml	  	<
./.gconf/desktop/gnome/peripherals/%gconf.xml		  	<
./.gconf/desktop/%gconf.xml				  	<
./.gconf/apps							./.gconf/apps
./.gconf/apps/panel					  	|	./.gconf/apps/aisleriot
./.gconf/apps/panel/applets				  	|	./.gconf/apps/aisleriot/rules
./.gconf/apps/panel/applets/clock_screen0		  	|	./.gconf/apps/aisleriot/rules/%gconf.xml
./.gconf/apps/panel/applets/clock_screen0/prefs		  	|	./.gconf/apps/aisleriot/%gconf.xml
							  	>	./.gconf/apps/devhelp
							  	>	./.gconf/apps/devhelp/ui
							  	>	./.gconf/apps/devhelp/ui/%gconf.xml
							  	>	./.gconf/apps/devhelp/%gconf.xml
							  	>	./.gconf/apps/evolution
							  	>	./.gconf/apps/evolution/addressbook
							  	>	./.gconf/apps/evolution/addressbook/%gconf.xml
							  	>	./.gconf/apps/evolution/calendar
.
.
.
.

Editiert am 3.Juli 2007:

Wenn ich mir das HOME-Verzeichnis und das Backup-Verzeichnis
mit "nautilus" ansehe, dann ist alles OK. Alle Dateien und Unterordner sind vorhanden.
Das nutzt mir allerdings nicht viel, weil ich die Prüfung in dem Backup-Skript unterbringen will.

Mit freundlichen Grüßen GBunge

Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von »GBunge« (7. Juli 2007, 19:00)

Regenbieger

unregistriert

2

Dienstag, 3. Juli 2007, 12:31

Geht es dir denn jetzt um die Funktion des Vergleichens oder um das vollständige Backup?

AFAIK führt rsync selbst Kontrollen darüber durch, dass beide Verzeichnisse gleich sind. Noch eine "manuelle" Kontrolle dürfte unnötig sein.

Ansonsten würde ich nach dem Erstellen der "Kontrolldateien" und vor dem Vergleich beide nach dem selben Prinzip sortieren.

lacarpe

ist fest eingezogen.

Beiträge: 509

Ubuntu: ---

Kernel: 2.6.32 (Debian Squeeze)

Desktop: Xfce

Architektur: 64-bit

3

Dienstag, 3. Juli 2007, 13:41

Wie lautet denn deine rsync-Anweisung genau? Ist sie wirklich auf einen 100% 1:1-Abgleich eingestellt?

Wenn ich mich recht erinnere, werden standardmäßig zum Beispiel Dateien, die in Source gelöscht wurden und sich bereits auf dem Target (aufgrund eines früheren Abgleichs) befinden, nicht auch auf dem Target gelöscht. Hierzu bedarf es der Option -delete.

Sprich: Es reicht ja schon eine Datei, die du in Source gelöscht hast, die aber auf Target verbleibt, und schon ist 1:1 nicht mehr gegeben.

Ich würde mal deine beiden Kontrolldateien per Auge vergleichen und schauen, an welcher Stelle sie das erste Mal voneinander abweichen.

Herzlicher Gruß,
lacarpe

ubuntufreund No. 30
think globally, act locally

GBunge

hat sich gut eingelebt.

Beiträge: 79

Architektur: 32-bit

4

Dienstag, 3. Juli 2007, 16:51

Hallo lacarpe,
ich poste hiermal meinen "rsync-Aufruf" im Sicherungsskript.

Quellcode

 option="-avz --delete --exclude \"*bak\" --exclude \"*~\""
 target="/media/usbdisk/Home"
 source="/home/bu/"
 exclude="/usr/local/bin/ex.home"

 rsync $option --exclude-from=$exclude $source $target

@Regenbieger
Natürlich führt "rsync" Kontrollen durch, aber beim Stöbern im Netz (Wiki, Foren)
hat es öfter den Hinweis gegeben, dass man doch lieber kontrollieren soll,
weil es auch schon Ereignisse dieser Art mit "rsync" gegeben hat.

Gruß GBunge

lacarpe

ist fest eingezogen.

Beiträge: 509

Ubuntu: ---

Kernel: 2.6.32 (Debian Squeeze)

Desktop: Xfce

Architektur: 64-bit

5

Dienstag, 3. Juli 2007, 17:32

Es ist recht wahrscheinlich, dass es an den exclude-Optionen liegt. Nehmen wir die "*bak"-Dateien: Es gibt solche Dateien in deiner Source (das nehme ich jedenfalls mal an, warum solltest du sie sonst exkludieren), aber mit rsync werden sie dann wegen der exclude-Option nicht nach Target überführt. Schwupps hast du kein 1:1-Abbild mehr. Kürzer ausgedrückt: Sobald eine Datei bei der Synchronisation (per -exclude) ausgeschlossen wird, hast du kein 1:1-Abbild mehr.

Gruß,
lacarpe

ubuntufreund No. 30
think globally, act locally

GBunge

hat sich gut eingelebt.

Beiträge: 79

Architektur: 32-bit

6

Mittwoch, 4. Juli 2007, 16:13

Hallo lacarpe,

mit Sicherheit liegt es an den "exludes". Aber dann hätten beim Anwenden von "diff" nur
diese Dateien im diff-Ergebnis auftauchen dürfen, und nicht ein Großteil alle Dateien, die
in beiden verglichenen Dateien gleich sind.
Die Sichtprüfung hat ja ergeben, daß alle Dateien kopiert wurden.
Ich interpretiere die Sache so, daß alle kopierten Dateien in beiden verglichenen Dateien
stehen, nur nicht an der gleichen Stelle.
Und damit wird die Anwendung von "diff" obsolet.

Gruß GBunge

lacarpe

ist fest eingezogen.

Beiträge: 509

Ubuntu: ---

Kernel: 2.6.32 (Debian Squeeze)

Desktop: Xfce

Architektur: 64-bit

7

Mittwoch, 4. Juli 2007, 16:48

Zitat von »GBunge«

Aber dann hätten beim Anwenden von "diff" nur
diese Dateien im diff-Ergebnis auftauchen dürfen, und nicht ein Großteil alle Dateien, die
in beiden verglichenen Dateien gleich sind.

Meiner Meinung nach ist es anders: Es reicht doch schon eine exkludierte Datei und alles danach verschiebt sich in deiner
Datei2.txt um eine Zeile nach oben. Und da diff zeilenweise vergleicht, stimmt eben aus Sicht von diff nichts mehr.

ubuntufreund No. 30
think globally, act locally

Regenbieger

unregistriert

8

Donnerstag, 5. Juli 2007, 09:43

Ich habe eben grade mal ein bisschen mit diff rumprobiert (zwei Dateien erstellt, eine mit 1,2,3,4,5 als Inhalt und eine mit 1,2,2,3,4,5) und Folgendes festgestellt - vielleicht hilft das ja bei deinem Problem.

diff vergleicht zwei Textdateien und gibt diejenigen Zeilen aus, in denen sich Datei1 und Datei2 unterscheiden. Jetzt habe ich aber festgestellt, dass - wenn du die Option "-y" verwendest, alle Zeilen ausgegeben und nur die Unterschiede entsprechend gekennzeichnet werden. Die gleichen Zeilen werden aber auch dargestellt - nur eben ohne Markierung. Bedeutet: sobald du -y als Option mitgibst, enthält das Ergebnis wesentlich mehr Zeilen als beide verglichenen Dateien.

Lässt du die Option -y weg, werden nur die Unterschiede dargestellt, aber vermutlich in einer Form, die du nicht möchtest ... nochmal zur Verdeutlichung mit obigem Beispiel (kannst du ja selbst ausprobieren):

	Quellcode
1 2 3 4 5 6 7	diff -y datei1.txt datei2.txt 1 1 2 2 > 2 3 3 4 4 5 5

	Quellcode
1 2 3	diff datei1.txt datei2.txt 2a3 > 2

Insofern dürfte die Aussage von GBunge^Wlacarpe nicht ganz korrekt sein (und meine Aussage oben mit dem Sortieren natürlich auch Quatsch) - sofern die Inhalte übereinstimmen, werden sie nicht als Unterschied gekennzeichnet, auch wenn sie in unterschiedlichen Zeilen stehen. (Wäre vermutlich auch fatal, wenn man mal an Diff-Dateien aus dem Kernel denkt mit mehreren Tausend oder Millionen Zeilen Code ...)

Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von »Regenbieger« (5. Juli 2007, 10:54)

GBunge

hat sich gut eingelebt.

Beiträge: 79

Architektur: 32-bit

9

Samstag, 7. Juli 2007, 11:16

Hallo Regenbieger,

was Du versucht hast, ist genau das, was ich gemacht habe.
Ich habe "diff" mit der Option -y aufgerufen. ( siehe ersten Post )
Die Ausgabe ist vergleichbar mit Deiner. Je nach Inhalt der Dateien
entweder auf der linken oder der rechte Seite Einträge.

Ich werde es also ohne die Option -y nochmals versuchen und erhalte dann
nur die Unterschiede, die ich entsprechend interpretieren muss!
Weiß aber noch nicht genau wie, weil ich den Vergleich ja in ein Skript
einbauen möchte, und abhängig vom Vergleichs-Ergebnis
einen Erfolg oder Misserfolg feststellen wollte.

Hallo lacarpe.
dein Hinweis trifft offensichtlich das Problem. Der Fehler war
die Option -y zu nutzen. Jede excludete Datei verschiebt dann das Bild
der Differenz so, wie in meinem ersten Post zu sehen ist.

Danke Euch beiden Gruß GBunge