[gelöst]Hidden Dot-files und rsync

[gm2601]

Hi Gurus,

in meiner Kiste befunden sich zwei gleiche WD-500GB-Platten gleicher Partitionierung mit 11.3.
SDA ist die "Normal"platte, SDB dient als fallback in case of...

Ich sichere $Home mit "rsync -ax --delete . /SDB3", habe nun aber über die firefox-history (STRG- h) festgestellt, daß diese nicht identisch ist.

Wie bekomme ich rsync dazu, auch die hidden Dot-files zu übertragen?
Ich bin aus den 2403 Zeilen von "man rsync" nicht recht schlau geworden, fühlte mich aber --wie üblich bei manpages-- an die Worte eines Instructors erinnert: "our manuals are written in a way, to keep us in business."

 

[gropiuskalle]

rsync kopiert versteckte Dateien per default (diese müssten ansonsten z.B. mit --exclude=".*/" ausgenommen werden).

Irgendwie kapiere ich Deine Syntax nicht so ganz; an Stelle von '.' würde ich mal den vollständigen Pfad des Quellverzeichnisses angeben, also z.B. /home/gm2601. /SDB3 klingt auch erst mal krumm, ich nehme aber an, dass das schon stimmen wird...

Insgesamt finde ich, dass Du die Möglichkeiten von rsync nicht ausreizt. Generiere Dir besser ein passendes Kommando mit einem rsync-tool wie luckyBackup und schaue Dir das Kommando dann mit Hilfe der man-Seiten genauer an.

Grundsätzlich sind man-Seiten übrigens nicht als HowTo gedacht, sondern als Nachschlagewerk - zumindest umfangreiche Kommandos lassen sich kaum über 'man' erlernen.

 

[josef-wien]

Der Befehl funktioniert, auch die mit einem Punkt beginnenden Dateien und Verzeichnisse werden kopiert, welchen Trugschluß willst Du mit

habe nun aber über die firefox-history (STRG- h) festgestellt, daß diese nicht identisch ist

beweisen?

 

[gm2601]

Irgendwie kapiere ich Deine Syntax nicht so ganz; an Stelle von '.' würde ich mal den vollständigen Pfad des Quellverzeichnisses angeben, also z.B. /home/gm2601. /SDB3 klingt auch erst mal krumm, ich nehme aber an, dass das schon stimmen wird...

der Punkt entspricht /home und sda3 von Platte 1, /SDB3 ist der mountpoint von /home und sdb3 der Platte 2.

Insgesamt finde ich, dass Du die Möglichkeiten von rsync nicht ausreizt. Generiere Dir besser ein passendes Kommando mit einem rsync-tool wie luckyBackup und schaue Dir das Kommando dann mit Hilfe der man-Seiten genauer an.

Zweifellos ein guter Gedanke, wenn man mit der Nase auf ein rsync-tool gestoßen wurde.

... welchen Trugschluß willst Du mit

habe nun aber über die firefox-history (STRG- h) festgestellt, daß diese nicht identisch ist

beweisen?

Beweisen will ich damit garnichts, ich ging von der Annahme aus, daß alles was an config und history des firefox' unter ~/.mozilla liegt und glaubte daher, daß ein rsync identische Daten unter .mozille erzeugt (.mozilla auf Platte 1, dann rsync und .mozille von Platte 2 sollte identisch sein)

 

[gropiuskalle]

der Punkt entspricht /home und sda3 von Platte 1, /SDB3 ist der mountpoint von /home und sdb3 der Platte 2.

Bis zum Punkt hab ich es noch verstanden, aber der Rest... sprichst Du die Zielpartition als device an oder heißt der Zielordner einfach /SDB3? Ist ja auch wurscht, prinzipiell scheinen da ja Daten zu landen.

Zweifellos ein guter Gedanke, wenn man mit der Nase auf ein rsync-tool gestoßen wurde.

Ich hab rsync so erlernt, nachdem ich am manual ebenfalls aufgrund der Masse zunächst scheiterte. luckyBackup hat so'n praktischen Knopf, der das rsync-Kommando auswirft, nachdem man sich ein Profil zusammengeklickt hat (und ist auch sonst eine sehr nette Sache). Mit diesem Kommando kann man die manpage von rsync etwas gezielter durchstöbern (wenn dann überhaupt noch Bedarf dafür vorhanden ist).

Beweisen will ich damit garnichts, ich ging von der Annahme aus, daß alles was an config und history des firefox' unter ~/.mozilla liegt und glaubte daher, daß ein rsync identische Daten unter .mozille erzeugt (.mozilla auf Platte 1, dann rsync und .mozille von Platte 2 sollte identisch sein)

Abgesehen von .mozille != .mozilla sollte das so sein, ja. Aber?

 

[gm2601]

Bis zum Punkt hab ich es noch verstanden, aber der Rest... sprichst Du die Zielpartition als device an oder heißt der Zielordner einfach /SDB3? Ist ja auch wurscht, prinzipiell scheinen da ja Daten zu landen.

Ok, ich werde mir nochmal Mühe geben:
Zwei gleiche 500GB-platten, mit identischer Aufteilung: sda1=sdb1=/, sda2=sdb2= swap, sda3=sdb3=/home. Beide Platten sind auch gleich installiert und in menue.lst alternativ zu booten. Default boot von sda, sdb läuft einfach mit. SDB3 ist der mountpoint für /home von Platte 2, und SDA3 der mountpoint von /home der Platte 1, falls von Platte 2 gebootet wurde. Der rsync soll mir /home auf beiden Platten identisch halten, was seit 9.x halbwegs klappte und mir schon mehrfach aus der Bredouille half.

Ich hab rsync so erlernt,....

Ob sich das für einen wie mich, der als single User an einem einsamen PC sitzt, wirklich auszahlt...?
Was ich bisher von luckyBackup sah, hat mir recht gut gefallen, der Simulationmode hat mir meine Skepsis genommen, der erste echte Lauf dauerte ca. 25min, der zweite, kurz danach um die 2min. Da ich das aus "init 5" machte, bin ich mit dem Vergleich durchaus zufrieden:

emil3:~ # ls -R /SDB3 | wc
 847616  794985 18041782
emil3:~ # ls -R /home | wc
 847604  794974 18041575

zumal nun auch die dot-directories identischen Inhalts sind. (Da bin ich anfangs einem Irrtum aufgesessen, da ich vergessen hatte, daß ich Platte 2 zwischendurch mal gebootet hatte. Sorry for that!)

Abgesehen von .mozille != .mozilla sollte das so sein, ja. Aber?

Womit mein Linux-Know-How schon hinreichend beschrieben ist, denn das habe selbst ich sofort verstanden.
Nun ist, besser war bis vor kurzem, ".mozilla = .mozilla"

Danke für die Tips.

 

[gropiuskalle]

Hauptsache, Du hast ein gutes tool gefunden. Ich finde luckyBackup für solche Szenarien eigentlich ideal.

 

[gm2601]

Doch, ist eine feine Sache!
Zwischenzeitlich wird auch der mount von /dev/sdb3 vor und der umount danach brav erledigt.

Mecker bekomme ich nur bei diesem file
rsync: readlink_stat("/home/guenter/.gvfs") failed: Permission denied (13)
was, wie ich gelesen habe, nicht tragisch, aber nervig ist, zumal ich KDE und nicht Gnome verwende.

Kann ich mich ohne übermäßigen Aufwand davon befreien?

 

[josef-wien]

Je nach dem Ergebnis von

rpm -qf ~/.gvfs

- das Paket löschen oder die Datei-/Verzeichnisberechtigungen anpassen
- das Verzeichnis löschen

 

[gm2601]

...oder die Datei-/Verzeichnisberechtigungen anpassen
- das Verzeichnis löschen

Das haut selbst unter root in /home/guenter nicht so einfach hin:

ll | grep gvfs
ls: Zugriff auf .gvfs nicht möglich: Keine Berechtigung
d?????????  ? ?       ?            ?             ? .gvfs
chmod 777 .gvfs 
chmod: Zugriff auf „.gvfs“ nicht möglich: Keine Berechtigung
rm -rf .gvfs 
rm: Entfernen von „.gvfs“ nicht möglich: Keine Berechtigung
??? Bringt das mehr Info?
stat ~/.gvfs
File: „/home/guenter/.gvfs“
  Size: 0               Blocks: 0          IO Block: 4096   Verzeichnis
Device: 11h/17d Inode: 1           Links: 2
Access: (0500/dr-x------)  Uid: ( 1000/ guenter)   Gid: (  100/   users)
Access: 2011-07-01 09:30:20.000000000 +0200
Modify: 2011-07-01 09:30:20.000000000 +0200
Change: 2011-07-01 09:30:20.000000000 +0200

Wenn ich von Platte 2 boote, dann habe ich es schon geschafft, .gvfs zu löschen, aber nach dem boot von Platte 1 wars wieder da.

Je nach dem Ergebnis von "rpm -qf ~/.gvfs" - das Paket löschen ...

rpm -qf ~/.gvfs       
file /home/guenter/.gvfs is not owned by any package                                                                                              
rpm -qa  | grep -i gvfs
gvfs-1.6.1-2.7.i586
gvfs-fuse-1.6.1-2.7.i586
gvfs-backends-1.6.1-2.7.i586
libgvfscommon0-1.6.1-2.7.i586
gvfs-backend-afc-1.6.1-2.7.i586

...was soll ich nun löschen, wenn überhaupt? Ich habe keine guten Erfahrungen irgendetwas mir "lib" zu löschen.

 

[Anonymous]

stat ~/.gvfs
File: „/home/guenter/.gvfs“
Size: 0 Blocks: 0 IO Block: 4096 Verzeichnis
Device: 11h/17d Inode: 1 Links: 2
Access: (0500/dr-x------) Uid: ( 1000/ guenter) Gid: ( 100/ users)
Access: 2011-07-01 09:30:20.000000000 +0200
Modify: 2011-07-01 09:30:20.000000000 +0200
Change: 2011-07-01 09:30:20.000000000 +0200

Was ist das für ein Filesystetype, wenn es ext2/3/4 ist dann folgendes.
size müsste bei Verzeichnissen irgend was stehen das durch 4096 teilbar ist, 0 ist bei ext2/3/4 Filesystemen bei Verzeichnissen nicht möglich
Blocks müsste irgendwas durch 8 teilbares stehen , 0 ist bei ext2/3/4 Verzeichnissen nicht möglich
Inode 1 muss auch falsch sein, die Inode 1 ist eine Reservierte Inode des Filesystems die kann gar nicht für eine Datei oder Verzeichnis verwendet worden sein.

Summa Summarum, das Filesystem hat meiner bescheidenen Meinung nach Fehler und einer davon in dieser Inode.

Filesystemcheck mit Option "-f" durchführen.

robi

 

[gm2601]

...
Summa Summarum, das Filesystem hat meiner bescheidenen Meinung nach Fehler und einer davon in dieser Inode.

Filesystemcheck mit Option "-f" durchführen.

Den touch habe ich gemacht, der reboot lief auch gut durch, kein Mecker während des (boot)fsck aber stat ~/.gvfs zeigte sich davon gänzlich unbeeindruckt.
Für einen "fsck -f -y /dev/sda2 oder sda3" fehlt mir im Moment der Mut, denn mein System läuft eigentlich ohne viel Mecker. Auch mein alternativboot von sdb läuft ohne viel Mecker.

Ist denn .gvfs (gnome virtuel file system, so habe ich gelesen) nicht etwas, was den KDE-User überhaupt nicht kratzen sollte?

 

[Anonymous]

Den touch habe ich gemacht, der reboot lief auch gut durch, kein Mecker während des (boot)fsck aber stat ~/.gvfs zeigte sich davon gänzlich unbeeindruckt.
Für einen "fsck -f -y /dev/sda2 oder sda3" fehlt mir im Moment der Mut, denn mein System läuft eigentlich ohne viel Mecker. Auch mein alternativboot von sdb läuft ohne viel Mecker.

Das brauchst du dann auch nicht mehr, der fsck ist beim booten dann schon erledigt worden.

Ist denn .gvfs (gnome virtuel file system, so habe ich gelesen) nicht etwas, was den KDE-User überhaupt nicht kratzen sollte?

Was immer das auch ist, es kann nichts mit der Inode 1 zu tun haben. Das ist für das Filesystem die Datei in der die Badblocks stehen würden, so es denn welche gäbe. Mit einer Größe 0 und ohne Blöcke als Verzeichnis ist es sinnlos.

Verwunderlich ist das es 2 Hardlinks haben soll, schau mal ob das nach dem Fsck jetzt auch noch so ist.
Ansonsten hab ich dieses Verzeichnis auch, aber das ist normal und funktioniert auch normal. Ach ja was mir noch einfällt, die Inode ist sowie so nicht in Ordnung, vielleicht sind dort auch noch irgendwelche Attribute, die sind nicht so leicht zu entdecken.

lsattr -a .gvfs

das ist normal

--------------- .gvfs/

und das könnte zB solche Meldungen und Probleme erklären

----i-d-------- .gvfs/

mit dem "i" dort, könnte man diese Datei nicht mal nach lost+found verschieben, ob sich da fsck zum reparieren rann wagen würde, weiß ich jetzt im Moment auch nicht.
Ist dort so was gesetzt, dann mal die Manpage von chattr lesen und erst einmal die Attribute entfernen die Löschen und Ändern verhindern könnten.

robi

 

[gm2601]

->lsattr -a .gvfs
lsattr: Unpassender IOCTL (I/O-Control) für das Gerät Beim Lesen der Flags von .gvfs/.
-------------e- .gvfs/..

Dieselbe Meldung kommt auch bei chattr.

Als root bekomme ich "Keine Berechtigung beim Auslesen des Status von .gvfs" für beide Kommandos (lsattr, chattr)

Starte ich von SDB, dann zeigt sich als User, wie als root folgendes:

emil3:/SDA3/guenter # ll | grep gv
drwx------  2 guenter users     4096 24. Jun 13:26 .gvfs
emil3:/SDA3/guenter # lsattr -a .gvfs/
-------------e- .gvfs/.
-------------e- .gvfs/..
emil3:/SDA3/guenter # chattr -e .gvfs/                                                                                                                                
chattr: Clearing extent flag not supported on .gvfs/

...und ich kann das file bzw. das directory per rm -r löschen.

Da das file mit jedem neuen boot wieder angelegt wird, mir offenbar keinen weiteren Ärger verursacht, denke ich, ich kann mit dem einen Mecker bei luckybackup leben. Obendrein brauch ich weder files, noch directories, die beim boot ohnehin erzeugt werden, im backup. (Ich zähle .gvfs künftig zur Kategorie "nice, but nor important to know")

======= Nachtrag, reichlich später ===========
Leider verhindert dieses dämliche directory den wunschgemäßen Clon von /home mit luckybackup, denn da bekomme ich nur die Meldung "Skipping deletion", da .gvfs auch einen readerror läuft.

 

[drcux]

Dieser Ordner existiert auch nicht wirklich, es ist ein virtueller Ordner und wird nur ins Dateisystem eingeblendet. Dein Dateisystem ist schon in Ordnung. Solche merkwürdigen Ordner hast du auch, wenn du zB. von entfernten Rechnern Verzeichnisse per sshfs oder ftpfs mountest.

Einfach beim Backup excluden:

http://luckybackup.sourceforge.net/features.html

Exclude option

Exclude any file, folder or pattern from the transfer.
You might not want to copy over backup files (*~), trash folders, system mount folders (/media & /mnt), some huge video files or anything else.

 

[gm2601]

Das habe ich versucht, auch der "validate" danach hat nicht gemeckert.

Aber da luckyBackup bereits beim Erstellen der filelist da drüberstolpert macht es anschließend den delete nicht, somit bekomme ich files, die ich gelöscht habe in "destination" nicht los.

Ich werde wohl wieder auf meinen ollen "rsync -ax --delete /home /SDB3" zurückgreifen, der dauert zwar deutlich länger, holzt aber einfach über den .gvfs-trouble drüber.

 

[gm2601]

... das Paket löschen

...Generiere Dir besser ein passendes Kommando mit einem rsync-tool wie luckyBackup...

Ich werde wohl wieder auf meinen ollen "rsync -ax --delete /home /SDB3" zurückgreifen, der dauert zwar deutlich länger, holzt aber einfach über den .gvfs-trouble drüber.

Da war wohl auch die Hoffnung der aber des Gedankens...ABER

Der anhaltende Zorn über nicht gelöschte Dest-files und die dämliche Meldung "rsync: readlink_stat("/home/guenter/.gvfs") failed: Permission denied (13)" haben mich nun soweit gebracht, daß ich --durchaus mit ein paar Angstperlen auf der Stirn--alles löschte, was der "rpm -qa | grep gvfs" hergab.
Man lese uns staune:
Jetzt klappts, wie gewünscht.

Meinen Dank an alle Helfer!

<---Der fehlt Euch hier