staging.inyokaproject.org

Hallo,

done. Fertigstellungsdatum bei Bedarf noch anpassen.

Gruß, noisefloor

Hallo Vej.

Gerade wollte ich etwas in der Beschreibung von rsync nachlesen, da stieß ich auf die Baustelle. Ich klickte rüber, überflog den Anfang und stieß auf etwas, das ich im ersten Augenblick für eine Inkonsistenz in der Beschreibung hielt. Nach etwas Nachdenken bin ich mir jedoch nicht mehr ganz sicher, wie es gemeint ist. Bitte schau doch mal kurz drüber:

Im Abschnitt "Anwendung" wird zur Darstellung der Syntax eine formale Grammatik verwendet, die ich beim ersten, flüchtigen Drüberschauen, aufgrund der verwendeten eckigen Klammern um "OPTIONEN", als EBNF interpretierte:

rsync [OPTIONEN] QUELLE(N) ZIEL 

Ich interpretierte die (in natürlicher Sprache?) formulierte Darstellung, dass rsync zwar mehrere "QUELLE"N-Angaben akzeptiert, jedoch mindestens eine benötigt.
Erst beim genaueren Durchlesen des darunterstehenden Kommentars stieß ich auf die Möglichkeit, dass die Angabe von "QUELLE(N)" auch als Ganzes optional ist.

Weil das theoretisch auch anderen Lesern passieren könnte, meine Frage:
Hat es einen bestimmten Grund, dass hier die auf den ersten Blick eindeutige EBNF-Notation

rsync [OPTIONEN] { QUELLE } ZIEL 

keine Verwendung findet?

gruß, hartmutf

Hallo hartmutf,

willkommen bei ubuntuusers.

hartmutf schrieb:

Hat es einen bestimmten Grund, dass hier die auf den ersten Blick eindeutige EBNF-Notation

rsync [OPTIONEN] { QUELLE } ZIEL 

keine Verwendung findet?

Wie bei vielen Befehlen ist es auch bei rsync nicht ohne weiteres möglich, eine korrekte und übersichtliche Notation in einer Zeile anzugeben. Es ist nämlich durchaus möglich, die Quelle oder das Ziel wegzulassen.

Siehe diese Auszug aus der Manpage:

SYNOPSIS Local: rsync [OPTION...] SRC... [DEST]

Access via remote shell: Pull: rsync [OPTION...] [USER@]HOST:SRC... [DEST] Push: rsync [OPTION...] SRC... [USER@]HOST:DEST

Access via rsync daemon: Pull: rsync [OPTION...] [USER@]HOST::SRC... [DEST] rsync [OPTION...] rsync://[USER@]HOST[:PORT]/SRC... [DEST] Push: rsync [OPTION...] SRC... [USER@]HOST::DEST rsync [OPTION...] SRC... rsync://[USER@]HOST[:PORT]/DEST

Usages with just one SRC arg and no DEST arg will list the source files instead of copying.

Wer auch immer damals diese Zeile eingefügt hat, wollte also vermutlich eine Konstruktion wie die Folgende vermeiden:

rsync [OPTIONEN] [(QUELLE(N) ZIEL)|ZIEL|QUELLEN] 

Was hältst du davon, zwei Zeilen anzugeben?

rsync [OPTIONEN] [QUELLE(N)] ZIEL 

rsync [OPTIONEN] QUELLE(N) [ZIEL] 

Das wird hier im Wiki öfters so gehandhabt

Viele Grüße

Vej

EDIT: Ich habe nochmal darüber nachgedacht und frage mich wie rsync Quellen von Zielen unterscheiden möchte, falls ich nur ein Argument angebe. Das muss ich mal genauer überprüfen.

Hallo Vej.

Ja, das ist so eine Sache mit Lesegewohnheiten. Für des Lesens formaler Grammatiken ungewohnter Nutzer ist dein Vorschlag mit den zwei Zeilen jedenfalls der lesbarste und eindeutigste, finde ich. (Ich glaube, Niklaus Wirth ist auch mehr als einmal an reiner BNF verzweifelt, deshalb hat er sie ja auch "Extended").

Was deine Zusatzfrage angeht, könnte ich mir vorstellen, dass sich rsync das aus dem Kontext interpretiert: eine einzige Angabe und als Verzeichnis oder Datei vorhanden ⇒ QUELLE, sonst ZIEL. Ich habe auch gerade mal einen Blick in die manpage riskiert, aber außer dem Hinweis, dass die Nichtexistenz von SRC als "default directory" interpretiert wird (wobei mir noch unklar ist, ob damit das HOME-DIR oder das CURRENT-DIR gemeint ist) habe ich nichts gefunden. Wird wohl auf einen Test hinauslaufen.
Aber bevor ich das kläre, verschwinde ich jetzt erstmal ins Freie, sonst ist die Sonne für heute weg.
gruß, hartmutf

Hallo,

Hat es einen bestimmten Grund, dass hier die auf den ersten Blick eindeutige EBNF-Notation

Ja, weil die Konvention hier anders ist: eckige Klammern bedeuten einen optionalen Eintrag, Einträge ohne Klammern einen nicht-optionalen. Falls du da Diskussionsbedarf sieht → bitte eine eigene Diskussion starten und nicht hier im Thread zum rsync Wikiartikel diskutieren.

Abgesehen davon beziehst du dich auf eine Baustelle - die kann aber jeden Zustand von total falsch bis völlig korrekt haben.

Gruß, noisefloor

Hallo noisefloor.

noisefloor schrieb:

Abgesehen davon beziehst du dich auf eine Baustelle - die kann aber jeden Zustand von total falsch bis völlig korrekt haben.

Das ist zwar richtig, aber in rsync ist es ja nicht anders (ich hatte auch eigentlich nicht vor diesen Abschnitt anzufassen). Deshalb finde ich den Hinweis von hartmutf berechtigt.

Viele Grüße

Vej

Liebes Wikiteam,

der Artikel (insbesondere der überarbeitete Abschnitt "Verzeichnisse von der Sicherung ausschließen") ist jetzt so gut, wie ich ihn im Moment hin bekomme. So richtig übersichtlich finde ich das zwar selber nicht, aber alle anderen Versuche wurden – bei den vielen gegenseitigen Beeinflussungen der Optionen – einfach zu langatmig.

Perspektivisch wäre natürlich ein Abschnitt der Ausschlüsse auch mit -R betrachtet wünschenswert. Allerdings wird das von meiner Seite vor März 2016 wohl nichts werden.

Von mir aus könnt ihr daher gerne verschieben.

Viele Grüße

Vej

Verschoben mit Dank für die Überarbeitung an Vej & frohe Weihnachten!

Dank für die Überarbeitung!

Die Client-Server Beschreibung verwendet jedoch nicht die offiziellen Bezeichnungen. "Freigaben" sollten "Module" heißen.

Und bei den Beispielen gehört doch die Angabe von <user>@<Server> eigentlich nicht zur Quelle, sondern zum Ziel. Hier meine Befehlszeile, um das aktuelle Verzeichnis $PWD auf meinem NAS im Modul $MODULE zu sichern:

rsync $RS_OPTIONS $RS_PW $PWD $USER@$HOST::$MODULE

Zur Info:
$RS_PW ist der Name mit Pfad zu einer Datei mit dem zugehörigen Passwort für den rsync-Server.
$RS_OPTIONS ist wohl selbsterklärend 😉

Gruß,
Ingo

rsync/#Lokales-Verlinken-ganzer-Verzeichnisstraenge hinzugefügt. Bitte mal drüberschauen, danke!

Hallo,

IMHO ok.

Gruß, noisefloor

Hallo ingo2.

ingo2 schrieb:

Die Client-Server Beschreibung verwendet jedoch nicht die offiziellen Bezeichnungen. "Freigaben" sollten "Module" heißen.

Du kannst das gerne anpassen ☺ .

Diesen Abschnitt habe ich auch gar nicht angefasst, mir ging es primär um die unvollständige und leicht falsche Darstellung bezüglich der Dateipfade in Kombination mit exclude.

Vielen Dank im Voraus

Vej

Hallo andi11,

du hast heute gestern rsync bearbeitet und

aktiviert einen Dateivergleich basierend auf Checksumme und nicht auf Größe und Timestamp. Die eigentlich Checksummenbildung kann etwas länger dauern als der Vergleich Größe und Timestamp, aber überflüssige Kopiervorgänge bei nur geänderten Timestamps werden vermieden.

zu

aktiviert einen Dateivergleich basierend auf Checksumme und nicht auf Größe und Timestamp. Die eigentlich Checksummenbildung dauert deutlich länger als der Vergleich Größe und Timestamp; andererseits werden überflüssige Kopiervorgänge (z.B. bei nur geändertem Timestamp) vermieden.

geändert.

Mich würde interessieren, warum du das als Beispiel umformuliert hast. Ich meine, was sonst sollte dazu führen, dass beim Vergleich mit Zeitstempel kopiert wird und beim Vergleich mit Checksumme nicht?

Vielen Dank und viele Grüße

Vej

PS.: Nutzer ist natürlich angeschrieben.

Ich hatte mit dem umgekehrten Fall bei System-Backups zu kämpfen.

Da die Option "-c" wirklich sehr lahm ist (Sicherung auf ein ARM-Device) und ich sie deshalb meide, passiert(e) es, daß 2 Files bei unterschiedlichem Inhalt gleiche Size und gleichen bzw. keinen Timestamp haben/hatten:

FILE_1="./usr/share/iceweasel/browser/defaults/preferences/webide-prefs.js" 
FILE_2="./usr/share/iceweasel/browser/defaults/preferences/firefox.js"

und dadurch nicht ins Backup übertragen werden!

Abhilfe ist ein touch der Files vor einem rsync-Backup in meinem Script.

Wozu? Entweder sichert man doch alles. Oder differentiell. Wozu brauchst du da was, was sich nicht geändert hat? Ich lass mir davon mit der Methode differentiell einfach Hardlinks erstellen. Also wie ist dein Setup, dass das für dich ein Problem ist?