rsync: kopiert statt abzugleichen

lab

lab

Mitglied
Thread Starter
Dabei seit
02.08.2006
Beiträge
67
Reaktionspunkte
3
Hallo Unix-Kenner

Durch dieses Forum motiviert habe ich mich etwas in UNIX eingearbeitet und schliesslich ein kleines Script erstellt, dass den Dokumente-Ordner zwischen meinem Mac und dem Laptop synchronisiert:

Code: 
mkdir /Volumes/lab
mount_afp -i afp://lab@Laptop.local/lab /Volumes/lab
echo "Sync begonnen um:" >> $HOME/Library/Logs/sync.log
date >> $HOME/Library/Logs/sync.log
rsync -vauE /Users/lab/Documents/Dokumente/ /Volumes/lab/Documents/Dokumente/
rsync -vauE /Volumes/lab/Documents/Dokumente/ /Users/lab/Documents/Dokumente/
echo "Sync beendet um:" >> $HOME/Library/Logs/sync.log
date >> $HOME/Library/Logs/sync.log
echo "==========" >> $HOME/Library/Logs/sync.log
umount /Volumes/lab

Das Ganze funktioniert brav - ausser, dass es eine Datei jedesmal ganz kopiert, obwohl ich eigentlich die Update-Option gesetzt habe... Sollte hier nicht einfach Dateiname und Datum (-u) verglichen werden - und wenn identisch keine weitere Aktion unternommen werden (also nicht kopieren...). Wo liegt mein Denkfehler? :confused:

Ausschnitte aus dem Terminalfenster:

Code: 
A/B/C/D/file.psd
    33768356 100%    1.75MB/s    0:00:18  (147, 10.4% of 1815)
Da wurde die ganze Datei kopiert...


Code: 
sent 158003057 bytes  received 13260 bytes  1848144.06 bytes/sec
total size is 296277691  speedup is 1.87
Zu viele Daten wurden verschoben, oder? Mein Dokumentordner umfasst bloss 300MB

Vielen Dank für Antworten!
 
Such mal im Forum nach dem Backup Thread. Da wird rsync Komplett behandelt und du musst nicht extra nen neuen Fred aufmachen ;)
Die SuFu ist oben im Menu. Sheep hat den Thread erzeugt...
 
Habe die Frage dort vor einiger Zeit gestellt und bisher keine Antwort erhalten, auch die Suche in den weiten des Internets hat keine Lösung gebracht. sheeps hervorragender Thread hat mich überhaupt erst auf den Geschmack gebracht...
 
rsync überträgt auch ohne den Schalter -u nur Dateien, die sich unterscheiden.
Also bei mir funktioniert folgendes (hier mit kleinen Beispieldateien):
Code: 
ls -l quelle/ ziel/
quelle/:
total 40
-rw-r--r--   1 maceis  martin  21 29 Okt 17:58 file1
-rw-r--r--   1 maceis  martin   7 29 Okt 17:57 file2
-rw-r--r--   1 maceis  martin   0 29 Okt 17:53 file3
-rw-r--r--   1 maceis  martin   7 29 Okt 17:58 file4
-rw-r--r--   1 maceis  martin   0 24 Jan 05:31 file5
-rw-r--r--   1 maceis  martin   0 24 Jan 05:31 file6
-rw-r--r--   1 maceis  martin   7 29 Okt 17:59 file7
-rw-r--r--   1 maceis  martin  11 29 Okt 17:59 file8

ziel/:
Jetzt füre ich rsync durch:
Code: 
rsync -av quelle ziel 
building file list ... done
quelle/
quelle/file1
quelle/file2
quelle/file3
quelle/file4
quelle/file5
quelle/file6
quelle/file7
quelle/file8

sent 569 bytes  received 180 bytes  1498.00 bytes/sec
total size is 53  speedup is 0.07
Ich verändere file1 und file2 und führe rsync erneut durch
Code: 
touch quelle/file{1,2}

rsync -av quelle ziel
building file list ... done
quelle/file1
quelle/file2

sent 288 bytes  received 60 bytes  696.00 bytes/sec
total size is 53  speedup is 0.15
Und siehe da; wie erwartet werden nur geänderte Dateien übertragen.
 
Wenn der Schalter -E eingeschaltet ist kopiert er einiges mehr. Das konnte ich auch schon beobachten. Das sind dann irgendwelche ._-Dateien; soviel ich weiss ist dies der Ressource-Fork einer Datei. Wieso rsync dies auch bei nicht geänderten Dateien macht, ist mir schleierhaft und störrt mich.

Zum Testen:
Code: 
rsync -vauE Documents/Anderes Desktop
rsync -vauE Documents/Anderes Desktop
 
Ach übrigens, weil ich's grad' seh'.
Es geht auch sowas:
Code: 
echo -e "Beendet: " `date +%d.%m.%y\ -\ %H:%M:%S` "\n----" >> $logfile
 
Update von der Befehlszeilen-Front:

Das Problem scheint mit dem -E-Schalter zusammenzuhängen. Wenn ich nämlich auf diese Option verzichte, wird nur kopiert, was sich verändert hat. Der Datenfluss umfasst blosse 26kb. Kaum schalte ich -E wieder ein, wird wieder jedesmal alles kopiert...? Mit -E sehe ich (wie zu erwarten), dass "extended" ._xyz-Dateien übertragen werden, aber eben auch die eigentlichen Dateien selbst.

In man rsync steht, dass -E "extended attributes, resource forks, and ACLs" kopiert. Mit diesem zusätzlichen Wissen google ich und stosse bald auf Folgendes (Mailing-List, also nicht Apple-offiziell):

Code: 
"rsync status in 10.4.7
- preserves ACLs on files w/o Extended Attributes, yet mangles the ACL's private EA values
- crashes copying files with both ACLs and Extended Attributes
- fails to copy Extended Attributes, generates warning
- fails to maintain creation dates, munges with modification date
- fails to maintain BSD (chflag) flags
- symlink ownerships are preserved
rsync should be avoided for copying files unless you can live with the above limitations"
Fand keine Hinweise darauf, dass sich unter 10.4.8 etwas geändert hätte.

Wie handhabt ihr das mit dem -E-Schalter? Was ist der "worst case", wenn man die Metadaten einfach nicht abgleicht?
 
Du wirst es nicht glauben, aber eben war ich auf der selben Seite und wollte Dir gerade diese Informationen geben.

Das Problem ohne dn Schalter -E zu syncen, ist, dass die Metadaten verloren gehen, Dateien werden nicht mehr mit dem "richtigen" Icon angezeigt, nicht mehr vom richtigen Programm geöffnet, Previews gehen verloren usw.
Nicht schön.
 
Vielleicht wird es ja mit 10.4.9 besser.

Apple has seeded Mac OS X 10.4.9 (8P2111) to developers tonight. The newest version of Tiger (10.4) promises fixes to a number of areas.

A number of fixes have been documented. Among those, include bugs wtih Sync Service Engine, rsync and extended attributes, […]
Zum Vergrößern anklicken....
 
Super! 10.4.9 wird ein wichtiges Update - Bluetooth soll auch verbessert werden. Vielleicht funktioniert dann auch endlich meine MightyMouse zuverlässig...
 
Komisch, dass nur rsync erwähnt wird.
'tar' ist nämlich auch betroffen, da das Problem anscheinend auf copyfile() zurückgeht.
 
Hier noch ein paar weitere Informationen:
Die "aktuelle" Version (2.6.3) von rsync, die in Tiger enthalten ist, ist ca. 2-3 Jahre alt. Inzwischen gibt es eine Version 2.6.8 für Mac OS X und sogar 2.6.9 auf der samba Seite.

Weitere Details:
http://www.onthenet.com.au/~q/rsync/
http://rsync.darwinports.com/

Ab Version 2.6.4 gibt es übrigens einen Schalter -i, der zusätzliche Statusinformationen liefert (Hab's selbst noch nicht ausprobiert).
 
Tecalto schrieb:
Der zweite Link scheint zu funktionieren, bzw. was dort beschrieben wird. Bei mir wird dann das neue rsync unter /opt/local/bin/rsync gesichert.
Der erste Testlauf war erfolgreich.
Zum Vergrößern anklicken....

Klappt doch nicht -E hat hier eine andere Funktion:
Code: 
 -E, --executability         preserve the file's executability
 
Interessant! Muss ich demnächst ausprobieren. Meines Wissens ist -E eine Apple-Funktion, fehlt also bei "direkten" rsync-Installationen.
 
schlimmer noch, der Schalter -E fehlt nicht, sondern hat eine andere Bedeutung, was die Erstellung von portablen Skripten nicht unbedingt vereinfacht.

Man kann die Original Quellen zwar für Mac OS X patchen, das ist mir aber nicht so gelungen, dass -E und Accesslisten unterstützt werden. Die Dokumentation ist diesbezüglich leider seh sparsam.
 
Hier noch ein Auszug, was 10.4.9 bringt:
Code: 
- Fixed problem with rsync and extended attributes
- Fixed issue with rsync and the copying of mod times
Hoffentlich löst das unsere Probleme.
 
Hi,

eine kurze Frage:

Wenn ich rsync von darwinports installiere, welches rsync wird dann aufgerufen wenn ich im terminal rsync eintippe?


cu
KUmba
 
which rsync
 
KUmba schrieb:
...
Wenn ich rsync von darwinports installiere, welches rsync wird dann aufgerufen wenn ich im terminal rsync eintippe?
...
Zum Vergrößern anklicken....
Das, das im Suchpfad als erste gefunden wird.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben Unten