rsync in Popen verhält sich anders als bei direkten Aufruf

Wenn du dir nicht sicher bist, in welchem der anderen Foren du die Frage stellen sollst, dann bist du hier im Forum für allgemeine Fragen sicher richtig.
Antworten
jb_alvarado
User
Beiträge: 55
Registriert: Mittwoch 11. Juli 2018, 11:11

Hallo Allerseits,

ich bin gerade dabei ein Synchronisationsscript zu schreiben. Es soll einen lokalen Ordner mit einem remote Ordner über ssh abgleichen.

Der Original Ordner hat momentan ca. 730GB, in Zukunft wird dieser aber noch wachsen. Da auch mein lokaler Ordner über cifs gemountet ist, prüfe ich immer zuerst ob bestimmte Dateitypen drin sind, wenn sie das sind, wird ein "--delete" an den rsync Befehl angehängt.

Zusätzlich lasse ich nur gegen die Dateigröße prüfen, nicht Veränderungsdatum etc.

Jetzt ist mir beim testen allerdings aufgefallen, dass rsync anscheint alle Dateien die Umlaute enthalten gelöscht hat, und diese wieder neu hochläd. Mir ist vorher schon mal aufgefallen, dass python bei der Ausgabe gemeckert hat, dass es manche Zeichen nicht decodieren kann. Leider habe ich das ignoriert, bzw. beim line.decode einfach ein errors="ignore") angehängt... War nicht so klug :).

Kennt ihr dieses Phänomen und wisst ihr woran das liegt, bzw. wie ich das in den Griff bekomme?

Hier ein Code-Auszug:

Code: Alles auswählen

#!/usr/bin/env python3
# -*- coding: utf-8 -*-    # <--- kann das ein Problem sein?

# sync local <> remote clips
def transfer_clips():
    print('Sync clips...')
    extra = rsync_delete()

    cmd = [
        RSYNC_BIN, '-re', 'ssh -i ' + SSH_KEY, '--size-only',
        extra, TRANSFER_CLIPS_ROOT,
        'user@example.org:streamer/clips/']

    run = Popen(
        cmd, stdout=PIPE, stderr=STDOUT)

    for line in run.stdout:
        print(line.decode('utf-8', errors="ignore"))
Sirius3
User
Beiträge: 17711
Registriert: Sonntag 21. Oktober 2012, 17:20

Da Dateisysteme Namen nur als reine Bytes betrachten, ist es Aufgabe der Programme, die diese Dateinamen benutzen, das richtige Encoding zu benutzen. Wenn Du dann verschiedene Systeme hast, die anscheinend Dateien mit unterschiedlichem Encoding schreiben, kommt es zu Problemen.

In welchen Systemen mit welchem Encoding sind denn die Dateisysteme eingehängt und gibt es da Abweichungen?
jb_alvarado
User
Beiträge: 55
Registriert: Mittwoch 11. Juli 2018, 11:11

Sirius3 hat geschrieben: Donnerstag 9. August 2018, 09:17 Da Dateisysteme Namen nur als reine Bytes betrachten, ist es Aufgabe der Programme, die diese Dateinamen benutzen, das richtige Encoding zu benutzen. Wenn Du dann verschiedene Systeme hast, die anscheinend Dateien mit unterschiedlichem Encoding schreiben, kommt es zu Problemen.
Arg, das ist ja blöd... Hatte ich nicht mehr auf dem Schirm, dass das passieren kann.
Sirius3 hat geschrieben: Donnerstag 9. August 2018, 09:17 In welchen Systemen mit welchem Encoding sind denn die Dateisysteme eingehängt und gibt es da Abweichungen?
Also ursprünglich lief ein Shell Script (über msys2) auf einem Windows Computer, der die Daten von einem Samba Server geholt hat, und sie per rsync auf einen Linux Server kopiert hat. Von diesem Linux Server aus, sind dann die Dateien noch mal auf eine Storagebox kopiert worden. Die ist mit cifs eingehängt (mit mount Parameter: iocharset=utf8).

Jetzt kopiere ich gleich von einem lokalen Linux aus auf die Storagebox, über rsync/ssh. Wobei das Linux auch per cifs den Quellordner gemountet hat, zwar nicht mit iocharset, dafür hat der Samba Server allerdings unter den Globals unix charset = UTF-8.

Gleiches Phänomen kann ich auch unter MacOS beobachten, wenn ich da rsync ohne delete ausführe, habe ich nachher die Dateien doppelt auf der Storage Box :) ...
Benutzeravatar
__blackjack__
User
Beiträge: 13004
Registriert: Samstag 2. Juni 2018, 10:21
Wohnort: 127.0.0.1
Kontaktdaten:

Beim MacOS könnte es an der Normalisierung der Daten liegen. Es gibt in Unicode nicht nur eine Möglichkeit zum Beispiel Umlaute darzustellen. Man kann da für ein ä Beispielsweise entweder den Codpoint für das ä verwenden, oder den Codepoint für a gefolgt von dem für die Pünktchen:

Code: Alles auswählen

In [16]: print a
Hällö

In [17]: print b
Hällö

In [18]: a == b
Out[18]: False

In [19]: a, b
Out[19]: (u'H\xe4ll\xf6', u'Ha\u0308llo\u0308')
MacOS benutzt im Dateisystem die zweite Variante.
“Most people find the concept of programming obvious, but the doing impossible.” — Alan J. Perlis
jb_alvarado
User
Beiträge: 55
Registriert: Mittwoch 11. Juli 2018, 11:11

Das ist ja echt verzwickt...

Ich denke das kleinste Übel wird sein, den rsync Job fertig durch laufen zu lassen, und in Zukunft nur noch mit Linux auf die Storagebox drauf zugreifen zu lassen.

Oder gibt es da noch andere Möglichkeiten?

Rsync unter MacOS bekommt es generell nicht gebacken im Infobereich Umlaute richtig darzustellen. Habe ich lokal noch nicht beobachtet, nur bei dieser Storagebox...
Antworten