flickr Takeout – und nun?

Nachdem Flickr wurde vor einer Weile von SmugMug gekauft wurde, ließ die Ankündigung einer recht großen Änderung nicht lange auf sich warten: Free-Accounts werden auf maximal 1.000 Fotos begrenzt.

Das wäre für mich an sich nicht weiter schlimm, da ich bereits seit geraumer Zeit nichts mehr zu flickr hochgeladen habe. Dass aber auch Bilder von bestehenden Accounts gelöscht werden, bis sie unter die 1.000er Grenze rutschen ist dann doch etwas unglücklich, da ich doch gerne hin und wieder mal durch meine Alben blättere (von denen die meisten auf privat gestellt sind).

Zum Glück gibt es einen Take-Out mit welchem man sich seinen kompletten Flickr-Inhalt herunterladen kann: Metadaten wie Albumstruktur, Kommentare, Likes usw., aber auch alle Fotos in ihrer Originalversion.

Die Idee: mit einem simplen Skript könnte man sich so die Albumstruktur auf der lokalen Festplatte mit Directories nachbauen und dann die Bilder aus dem Take-Out-Archiv dort hinein kopieren und sich z. B. mit thumbsup eine eigene Web-Gallery erstellen.

Es gibt dabei nur ein Problem: die Bilder des Take-Outs lassen sich nicht den Meta-Daten zuordnen, da die Dateinamen der Bilder aus dem Archiv nirgends in den Metadaten vermerkt sind 🤦‍♀️

Zumindest geben die Metadaten aber Aufschluss über die URL der Bilder in Originalauflösung auf Flickrs CDN, so dass Struktur und Inhalte schlussendlich doch zueinander finden.

Ich habe mir auf die Schnelle™ ein Skript hingehackt, welches die Flickr-Albumstruktur lokal mit Verzeichnissen im Dateisystem abbildet, alle Bilder herunterlädt und korrekt einsortiert: Skript bei Github.

Disclaimer: „auf die Schnelle hingehackt“ ist genauso zu verstehen wie es dort steht. Schöpfungshöhe gegen null, kein Error-Handling, keine Best Practices, keine Garantie dass man am Ende nicht mit einer leeren Platte da steht.

find, xargs, sleep

Gegeben

  • Linux-Server
  • RAID-1 aus zwei SATA-Platten (spinning rust)
  • ext4 Filesystem
  • ein Directory-Tree mit vielen Millionen Files + Sub-Directories

Aufgabe

In diesem Tree rekursiv leere Sub-Directories finden und diese löschen.

Bonusaufgabe

Das Ganze soll auf einem Produktionsserver laufen, die I/O muss niedrig gehalten werden, um die eigentlichen Aufgaben des Servers nicht zu beeinträchtigen.

Hinweis

Es handelt sich um etwa 1 Million leere Directories, welche zum Schluss gelöscht werden müssen.

Ansatz 1

find + xargs

find . -type d -empty -print0 | xargs -0 rmdir -v

Löst die Aufgabe, allerdings geht die die Average Queue Depth für die Platten hier nach kürzester durch die Decke und der Maschine kann mit ihrem Storage nicht mehr viel anfangen. Die Bonusaufgabe wird damit zumindest nicht bestanden.

Ansatz 2

find + xargs + sleep: Nach dem Löschen von n Directories kurz warten, damit die Platten genügend Zeit haben, um ihre Aufgaben abzuarbeiten.

find . -type d -empty -print0 | \
xargs -0 -n 100 bash -c '{ rmdir "$@" ; sleep 3 ; }'

Löst Aufgabe + Bonus zufriedenstellend und reicht mir für die einmalige Anwendung.

HTML-Directory-Listing mit tree

Die meisten Webserver bringen eine Funktion mit, welche Directory-Listings dynamisch erzeugen und als HTML ausgeben kann.

Manchmal ist es aber nicht möglich, das eingebaute Feature des Webservers zu nutzen und man benötigt einen anderen Weg, um schnell eine Liste der Dateien in HTML auszugeben.

tree hilft in diesem Fall weiter – es hat nämlich neben der Ausgabe eines Plain-Text-Directory-Listings auch die Möglichkeit, das Listing als HTML zu rendern.

tree ist bei allen wichtigen Linux-Distribution verfügbar, auf macOS kann man es einfach per Homebrew installieren.

Ich habe es benutzt, um eine Liste von Bildern in einem Verzeichnis zu erstellen:

tree -H '.' -L 1 --noreport --charset utf-8 > index.html

Alle Optionen sind in der Manpage von tree ausführlich erklärt. Obiger Befehl erzeugt folgende HTML-Ausgabe:

Schöner Hack: Map Tiles zum Transportieren eines Protests

Oft nutze ich die Map Tiles von openstreetmap.de anstelle des gewohnten Designs von openstreetmap.org. Sie sind dem Original ähnlich genug um sich sofort zurechtzufinden, bilden aber bestimmte Details besser ab. So sind zum Beispiel „Pfade“ keine rot-gepunkteten, sondern grau-gestrichelte Linien, was einfach harmonischer wirkt.

Heute habe ich auf den Kartenkacheln von openstreetmap.de eine Form des politischen Protests gesehen, die ich so noch nicht kannte: zufällig werden Kacheln mit einem Hinweis auf die Gefahren der geplanten Uploadfilter der EU-Urheberrechtsrichtlinie unter die normalen Kartenkacheln gemischt, so dass die Karte in etwa folgendermaßen aussieht:

Wie ich finde eine sehr gelungene Form auf die Probleme hinzuweisen, die die neue Urheberrechtsrichtlinie potenziell mit sich bringt.

Direkter Link zur Protestseite bei openstreetmap.de.

OpenStreetMap und der Brückeneinsturz in Genua

Die Geschwindigkeit, mit der das OpenStreetMap-Projekt auf aktuelle Ereignisse reagiert ist immer wieder beeindruckend. Kurze Zeit nachdem der Einsturz eines Brückensegments der A10 bei Genua (Italien) bekannt wurde, sind die Kartendaten bereits angepasst:

Die Standard-Karte von OpenStreetMap kurz nach dem Einsturz des Brückensegments (Link, Karte: © OpenStreetMap contributors)

Die Brücke wurde bereits als bridge=collapsed umgetaggt, die Relation der A10 enthält zum aktuellen Zeitpunkt allerdings noch die südliche Fahrbahn:

Die Relation der A10 ist noch teilweise intakt (Link, Karte: © OpenStreetMap contributors)