Freigegebener Ordner mit Remote-Ordner synchronisieren

[Nixnuzz]

Update: Irgendwie hatte ich vorhin einen Knick im Auge (Ä) "und (Ö) werden anscheinend akzeptiert - das Problem betrifft bei genauerem Hinsehen nur Fragezeichen (?) und Anführungsstriche (").

Also kein Problem mit dem Zeichensatz - aber manche Zeichen haben eine besondere Bedeutung. Allgemein als "verboten" in Dateinamen gelten:

? * < > . , \ + : = / " ; [ ] |

Vielleicht fällt einem Forenkollegen noch etwas ein - ansonsten seh ich keine Lösung, ausser diese Zeichen aus den schon vorhandenen Dateinamen zu löschen - und deinen CD-Ripper so einzustellen, dass er auf deren Verwndung bei Erstellung der Dateinamen verzichtet.

 

[Brendianer]

Vielen Dank für die tolle Unterstützung.
Keine Ahnung, wie es dazu kommen konnte. Diese Files zeigen in im Dateimanager für diese Sonderzeichen ein Quadrat.
Es gilt jetzt mit Fliessarbeit, all diese Files zu korrigieren.
Der Abgleich über SSH hilft. MAn sieht da, welche Files es sind und man korrigiert fortlaufend.
Das ist jetzt mein defintiver "Befehl": rsync -t -u -v -r --delete --exclude="@*" /volume1/music/ /volume1/RoonServer/ROCK/
Ich gehe davon aus, dass der Parameter "-v" auch in der Aufgabe der Synology drin bleiben darf. Schade, dass man in der Synology das Protokoll nicht sehen kann. Folglich muss man wohl von Zeit zu Zeit einen Abgleich über SSH machen, damit man allfällige Fehler findet.
Beim Aufräumen der Verzeichnisse habe ich Folder gefunden, in denen "Thumbs.db" enthalten ist. Scheint ein Überbleibsel alter Windows-Versionen zu sein. Eigenartig bloss, dass der Synology Dateimananger danach nicht suchen kann.
Offen ist jetzt nunr noch, ob der Paramter --exclude="@*" richtig ist.

 

[Nixnuzz]

Zur praktischen Verwendung des Aufgabenplaners bin ich leider noch nicht vorgedrungen - keine Ahnung was der mit dem Output des Kommandos macht. Du kannst aber die Ausgabe von rsync (oder eines beliebigen Kommandos) ganz einfach in eine Datei schreiben:

MeinKommando >> Pfad_zur_Ablage/MeinKommandoOutput.txt

Das @* darf NICHT in Anführungszeichen. Ohne wird das * als Platzhalter für beliebe Zichenfolgen interpretiert - trifft also auf alle Dateien und Verzeichnise zu, die mit @ beginnen, MIT Anführungszeichen wäre diese Interpretation abgeschaltet. Wenn du per Kommandozeile zB mal auf /volume1/ schaust, findest du jede Menge von @irgendwas - wie es in den Unterverzeichnissen aussieht, hängt von den laufenden Diensten ab.

Thumbs.db werden meines Wissens auch von neueren Windowsversionen angelegt, bin aber nicht sicher. Wenn du die loswerden willst, kannst du sie folgendermassen suchen:

find Pfad_zum_Startverzeichnis -name Thumbs.db >> Pfad_zur_Ablage/AllemeineThumbs.txt

Gibt zwar auch Möglichkeiten, diese gleich automatisch zu löschen, aber das halte ich für zu riskant.

CDs-rippen ist bei mir ne Weile her - aber nach meiner Erinnerung bieten die einschlägigen Programme Einstellmöglichkeiten für die Regeln, nach denen die Dateinamen erzeugt werden, auch was den Umgang mit "verbotenen Zeichen" angeht. Wenn du also aktiv rippst, lohnt sich ein Blick da hinein.

Was mich interessieren würde - wie lange dauer ein rsync-Lauf bei dir - wenn es keine neuen Dateien zu kopieren gibt?

 

[Brendianer]

Vielen Dank erneut.
Habe leider die beiden Kommandizeilen nicht verstanden... bzw. wie man diese ergänzt.
Habe nun gefühlt rund - keine Ahnung - 2-3000 Files manuell korrigiert.
Jetzt erhalte ich keine Fehlermeldung mehr.
Der Abgleich dauert nun rund 25 Sekunden bei rund 90.000 Files.

 

[luddi]

Ich gehe davon aus, dass der Parameter "-v" auch in der Aufgabe der Synology drin bleiben darf. Schade, dass man in der Synology das Protokoll nicht sehen kann.

Ich sehe da 2 Möglichkeiten.

1. Man wählt bei den Aufgabeneinstellungen die Benachrichtigung entsprechend aus.
Dabei muss man darauf achten, dass der Haken unter Punkt 2 nicht gesetzt ist. Somit wird immer eine Benachrichtigung mit dem stdout der Konsole per E-Mail geschickt.



2. Man kann die Ausgabe in eine Datei umleiten

Option 1:

rsync -t -u -v -r --delete --exclude="@*" /volume1/music/ /volume1/RoonServer/ROCK/ > /volume1/<PATH>/$(date '+%Y-%m-%d_%H-%M')_log.txt

Option 2 (Ausgabe auf stdout und gleichzeitiges umleiten in eine Datei):

rsync -t -u -v -r --delete --exclude="@*" /volume1/music/ /volume1/RoonServer/ROCK/ | tee /volume1/<PATH>/$(date '+%Y-%m-%d_%H-%M')_log.txt

Offen ist jetzt nunr noch, ob der Paramter --exclude="@*" richtig ist.

Ja dieser Parameter ist richtig. Alle Verzeichnisse oder Dateien welche mit einem @ beginnen werden dabei ignoriert.

Das kann man überprüfen, indem man die Dateien mittels rsync mit dem Parameter --list-only nur auflisten lässt, ohne dabei eine Übertragung zu starten:

rsync --list-only -t -u -v -r --delete --exclude="@*" /volume1/music/ /volume1/RoonServer/ROCK/

 

[Nixnuzz]

Moin luddi, so ists natürlch noch besser - aber bist du dir sicher mit den Anführungszeichen?

ICH@NAS:/volume1/Testordner$ ls -l "@*"
ls: cannot access '@*': No such file or directory
ICH@NAS:/volume1/Testordner$
ICH@NAS:/volume1/Testordner$ ls -l @*
total 4
-rwxrwxrwx+ 1 ICH      users  238 Jan 11 16:25 'Kartierungen 2023.xlsx@SynoEAStream'
drwxrwxrwx  1 root      root    0 Feb 12 18:58  @recycle
drwxrwxrwx+ 1 root      root   60 Feb 13 07:00  sharesnap_share_configuration
drwxrwxrwt  1 root      root    0 Feb  4 13:06  @tmp
ICH@NAS:/volume1/Testordner$

 

[Brendianer]

Also ich bin total happy mit diesem Script:
rsync -t -u -v -r --delete --exclude="@*" /volume1/music/ /volume1/RoonServer/ROCK/ | tee /volume1/homes/MEINNAME/Drive/$(date '+%Y-%m-%d_%H-%M')_log.txt
Das war ein super tolle Unterstützung.
Könnte man das Script ergänzen, so dass die Dateien "Thumb.db" und ".DS_Store" nicht mitkopiert werden?

 

[luddi]

aber bist du dir sicher mit den Anführungszeichen?

Ja damit bin ich mir sehr sicher.
Du vergleichst hier nämlich Äpfel mit Birnen.

Das was du in deinem Post #26 in der Code Sektion zeigst, ist ein ls -l "@*". Das heißt du möchtest explizit eine Datei mit dem Namen @* auflisten. Ich bin mir sicher dass du in diesem Verzeichnis /volume1/Testordner keine Datei mit exakt diesem Namen liegen hast und aus diesem Grund erscheint die korrekte Fehlermeldung ls: cannot access '@*': No such file or directory.

Der Befehl ls verhält sich nämlich anders als rsync und sein Parameter --exclude.
Stellt man bei ls etwas in Anfürhungszeichen dann sucht man genau nach diesem Namen. Lässt man die Anfürhungszeichen weg so wird Asterisk als Platzhalter verwendet.
Bei rsync wird hingegen Asterisk direkt als Platzhalter betrachtet und möchte man tatsächlich nach dem Sternchen suchen dann muss man dieses Zeichen eben escapen.

Ich mache mal ein Beispiel:

1. Beispiel mit dem Kommando ls:

# Zunächst das Verzeichnis auflisten:
~/.tmp$ ls -l
total 0

# Suche nach dem besagten Namen mit Anführungszeichen, wird nicht gefunden
~/.tmp$ ls -l "@*"
ls: cannot access '@*': No such file or directory

# Datei Namens @* anlegen
~/.tmp$ touch "@*"

# Suche nach dem besagten Namen mit Anführungszeichen, wird gefunden
~/.tmp$ ls -l "@*"
-rw------- 1 root root 0 Feb 13 09:36 '@*'

# Suche nach Vorkommnissen die mit eine @ beginnen
~/.tmp$ ls -l @*
-rw------- 1 root root    0 Feb 13 10:19 '@*'

2. Beispiel mit dem Kommando rsync:

# Auflisten des leeren Verezicnis mit rsync
~/.tmp$ rsync -a --list-only /root/.tmp/
drwx------          4,096 2024/02/13 09:49:51 .

# Erstellen einer Datei Namens @* und eines Verzeichnis @eaDir
~/.tmp$ touch "@*" && mkdir @eaDir

# Auflisten mit rsync
~/.tmp$ rsync -a --list-only /root/.tmp/
drwx------          4,096 2024/02/13 09:59:49 .
-rw-------              0 2024/02/13 09:59:49 @*
drwx------          4,096 2024/02/13 09:59:49 @eaDir

# Auflisten mit rsync und alle Vorkommnisse die mit @ beginnen ausschließen
~/.tmp$ rsync -a --list-only --exclude="@*" /root/.tmp/
drwx------          4,096 2024/02/13 09:59:49 .

# Auflisten mit rsync und jetzt alle Vorkommnisse ausschließen die mit @* beginnen
~/.tmp$
rsync -a --list-only --exclude="@\*" /root/.tmp/
drwx------          4,096 2024/02/13 09:59:49 .
drwx------          4,096 2024/02/13 09:59:49 @eaDir

Jeder Befehl arbeitet nämlich anders und muss dementsprechend mit der für ihn vorgesehenn Syntax behandelt werden.

 

[luddi]

Könnte man das Script ergänzen, so dass die Dateien "Thumb.db" und ".DS_Store" nicht mitkopiert werden?

Ja selbstverständlich. Dazu gibt es mehrere Lösungsansätze.

Option 1:

# Für jedes exclude explizit je einen Parameter verwenden
rsync -t -u -v -r --delete --exclude="@*" --exclude="Thumb.db" --exclude=".DS_Store" /volume1/music/ /volume1/RoonServer/ROCK/ | tee /volume1/homes/MEINNAME/Drive/$(date '+%Y-%m-%d_%H-%M')_log.txt

Option 2:

# Alle Excludes in einen Parameter packen (entspricht ODER Verknüpfung)
rsync -t -u -v -r --delete --exclude={"@*","Thumb.db",".DS_Store"} /volume1/music/ /volume1/RoonServer/ROCK/ | tee /volume1/homes/MEINNAME/Drive/$(date '+%Y-%m-%d_%H-%M')_log.txt

Option 3:

# Man verwendet den Parameter --exclude-from und gibt eine extra Datei an in der die Excludes zeilenweise aufgelistet sind
rsync -t -u -v -r --delete --exclude-from=/volume1/<PATH>/excludes.txt /volume1/music/ /volume1/RoonServer/ROCK/ | tee /volume1/homes/MEINNAME/Drive/$(date '+%Y-%m-%d_%H-%M')_log.txt

# Dabei sieht der Inhalt der Datei excludes.txt wie folgt aus:
@*
Thumb.db
.DS_Store

 

[Brendianer]

Perfekt vielen Dank!
Und wie würde man bereits Kopierte wieder löschen? Das Script hat keine gelöscht; aber ich gehe davon aus, dass es solche Files auf dem Zielverzeichnis bereits hat.

 

[luddi]

Ich hätte jetzt gedacht dass der Parameter --delete bereits dafür sorgt. Laut Beschreibung sollte genau dies passieren.
Das Verhalten muss ich wohl selbst einmal nachstellen.

 

[luddi]

Ich habe das ganze einmal bei mir nachgestellt und komme zu folgendem Ergebnis.

Man muss hierfür einen weiteren Parameter verwenden
--delete-excluded -> also delete excluded files from dest dirs

 

[Brendianer]

Perfekt!!!

Der Aufgabenplaner hat eine geplante Aufgabe abgeschlossen.

Aufgabe: ROCK rsync
Start: Tue, 13 Feb 2024 11:53:49 +0100
Ende: Tue, 13 Feb 2024 11:54:38 +0100
Aktueller Status: 0 (Normal)
Standardausgabe/Fehler:
sending incremental file list
deleting @eaDir/The Beatles - Revolver@SynoResource
deleting @eaDir/
deleting .DS_Store
deleting Diverses/.DS_Store
deleting FLAC/.DS_Store
deleting FLAC/10cc/.DS_Store
deleting FLAC/3 Doors Down/.DS_Store
deleting FLAC/311/.DS_Store
deleting FLAC/4 Non Blondes/.DS_Store
deleting FLAC/A.J. Croce/.DS_Store

...und im 2. Durchgang leer:

Der Aufgabenplaner hat eine geplante Aufgabe abgeschlossen.

Aufgabe: ROCK rsync
Start: Tue, 13 Feb 2024 11:57:03 +0100
Ende: Tue, 13 Feb 2024 11:57:29 +0100
Aktueller Status: 0 (Normal)
Standardausgabe/Fehler:
sending incremental file list

sent 6,141,730 bytes received 11,541 bytes 223,755.31 bytes/sec
total size is 2,585,332,901,185 speedup is 420,155.87



Von BrendenNAS

 

[luddi]

Genau so muss das sein. Freut mich, dass es klappt

 

[Brendianer]

Mit welchem Befehl könnte man denn diese Dateien auf dem Ursprungsverzeichnis löschen?

 

[luddi]

Du meinst diese in dem Ursprungsverzeichnis suchen und löschen?

z. B. hiermit mit der Annahme dass wie aus den vorherigen Aufrufen /volume1/music/ das Ursprungsverzeichnis ist:

find /volume1/music/ -type d -name "@eaDir" -o -type f -name ".DS_Store" | xargs rm -rf

Das Problem ist aber, dass die @eaDir Verzeichnisse und die .DS_Store Dateien jeweils wieder angelegt werden können.
Bei den @eaDir ist Synology DSM und bei den .DS_Store ist Mac OS dafür verantwortlich.

Für Mac OS gibt es eine Lösung, dass diese Dateien bei einer Netzwerkverbindung wie SMB erst überhaupt nicht angelgt werden.
Dazu kann man z. B. TinkerTool verwenden.

 

[Nixnuzz]

Der Befehl ls verhält sich nämlich anders als rsync und sein Parameter --exclude.

Ah ok. Ich war der Meinung, dass die Dateinamensererweiterung eine Funktion der Shell ist, und dass commandos wie ls, cat, cp, mv, rm usw. auf dieser Funktionalität aufbauen. Wusste nicht, dass rsync das anders macht ...

Wieder was dazugelernt, Danke für die ausführliche Darstellung

Was mich noch interessieren würde - wie kann man im Script sicherstellen, dass die SMB-Freigabe tatsächlich gemountet ist?
Wenn sie es aus irgendwelchen Gründen nicht ist - sieht rsync den Mountpoint nur als leeres Verzeichnis - und würde die ganze Musiksammlung dorthin kopieren ... richtig?

 

[luddi]

Sehr gerne.

Falls es dich interessiert wie rsync mit den Include und Exclude Patterns umgeht, kannst du gerne im Detail in diesem rsync manual nachlesen.
rsync: INCLUDE/EXCLUDE PATTERN RULES

 

[Nixnuzz]

Oops - jetzt warst du aber schnell - hab oben noch einen Abschnit hinzugefügt. Kannst du darauf noch kurz eingehen?

 

[luddi]

wie kann man im Script sicherstellen, dass die SMB-Freigabe tatsächlich gemountet ist?

Das kann man mit dem Befehl mount erreichen.

Hier ein Beispiel:

if mount -l | grep //192.168.135.251/home > /dev/null; then
    echo YES
else
    echo NO
fi

In dem Pfad mit dem echo YES fügst du den rsync Befehl ein um diesen nur auszuführen wenn das SMB Verzeichnis auch eingebunden ist.

und würde die ganze Musiksammlung dorthin kopieren ... richtig?

Das ist korrekt und würde so den lokalen Speicherplatz verschwenden.