Ich hab hier #NextcloudAIO auf einem #Zimablade laufen.
Und ich hab eine spezielle Anforderung... selbstgewählt natürlich.
Ich hab mir mal ein Script geschrieben, dass alle möglichen Dateinamen von Kameras frisst und ggfs. aus dem Dateinamen ein Erstellungsdatum auslesen kann, so keines in den #EXIF Daten des Bildes festgelegt ist.
Am Ende der Behandlung mit dem Script steht dann ein Erstellungsdatum in den Exif-Daten und der Dateiname folgt der Konvention YYYYMMDD-HHMMSS.<dateierweiterung>
Die Idee dahinter war, dass die Bilder auch bei einem Shell-Dateilisting in der richtigen zeitlichen Reihenfolge aufgelistet werden, und dass auch Bilder/Videos in denen keine Metadaten zur Erstellung gespeichert sind, diese bekommen und in div. Zeitleisten in Nextcloud auch richtig geordnet aufscheinen.
Sonst ist mir das nämlich zuviel Chaos.
Gut. Das Script hab ich schon lange im Einsatz und funktionierte auf meiner alten Nextcloud (bare-metal) und auf einem NAS gut und machte, was es soll.
Mit incron habe ich den Upload-Ordner (Bei der Nextcloud meistens SofortUpload benannt) überwacht und das Script sprang dann bei jedem neuen File dort an und verschob es umbenannt in ein Verzeichnis + Subdir nach YYYY/YYYY_MM
Ab und zu einmal hängte sich incrond auf... war nicht schön, aber handlebar.
Zweite Herausforderung bei der #Nextcloud:
Wenn ich im Filesystem direkt herumpfusche, kriegt die Nextcloud das nicht mit. Die Files bleiben so lange unsichtbar, bis ich mit occ files:scan wieder alles neu einlese.
Das dauert aber laaaaaaaange. Denn ich habe viiiiiiiele Files.
Alternativ kann ich mit dem config-Parameter 'filesystem_check_changes' => 1, auch ein Verzeichnis beim öffnen von der Nextcloud indizieren lassen... nicht schön, denn das haut die ohnedies nicht überragende Performance der Nextcloud ziemlich zusammen. Und zwar immer. Egal ob nun files neu eingelesen werden müssen, oder nicht.
Au0erdem hat incrond ein Problem. Dazu gibts schon länger einen Bugreport von mir, der aber schon über ein Jahr nicht behandelt wurde... wenn ich ein Verzeichnis lösche, haut es incrond auf und es stürzt ab. Außerdem ist die Performance beim rekursiven Überwachen schlecht... es stürzt manchmal aus unerfindlichen Gründen ab.
Also bin ich auf inotifywait gekommen. Das scheint viel stabiler als incron zu sein (baut aber auf der selben Kernel-Schnittstelle auf).
Jetzt hab ich mein Script so angepasst, dass ein Script den Upload-Ordner überwacht, und für jedes hochgeladene File einen batch-Job erstellt, damit das Bild dann mit meinem Script behandelt wird, wenn die Last am Serverchen niedrig ist... so bleibt die Nextcloud immer erreichbar, auch wenn ich viele Bilder gleichzeitig hochlade.
Ein zweites Script überwacht dann das "files" Verzeichnis aller User auf Änderungen und schreibt den Dateinamen samt Pfad eines hinzugekommenen Files oder das Parent-Verzeichnis eines entfernten Files/Verzeichnisses in verschiedene Stapel-Files. Da diese Filenamen auch mehrfach vorkommen können, brauchts dann noch einen Cronjob:
Diese list diese Stapelfiles aus, macht ein sort|uniq drauf und schreibt das Ergebnis in ein Tempfile und trunkated gleichzeitig das Stapelfile, welches damit wieder vom Script neu befüllt werden kann.
Dann führt es mit docker exec im Nextcloud-Container der Nextcloud AIO ein occ files:scan bzw. occ groupfolders:scan mit einer --path= Angabe aus um wirklich nur die veränderten Verzeichnisse und Files einzulesen. Das geht VIEL schneller, als regelmäßig den gesamten Inhalt zu scannen. Und es haut mir die Performance am Frontend nicht zusammen, wenn ich mehrere Verzeichnisse nacheinander aufrufe.
Klingt kompliziert?
Ist es auch.
Aber momentan scheint es zu funktionieren.
#scripting #bash #docker
