Arch Linux

Thunar: Zeitstempel in Vorschaudateien mit Nanosekunden

Dakuan

Ich experimentiere seit einigen Zeit mit der Erstellung von Vorschaudateien, speziell für Videos.
Jetzt bin ich darüber gestolpert, dass Thunar beim Veränderungsdatum der Originaldatei (Chunk Thumb::MTime) auch die Nanosekunden angibt und dies auch bei vorgefundenen Vorschaudateien erwartet.
Das führt dazu, dass meine Dateien und auch die, die von anderen Programmen wie z.B. Caja erzeugt wurden, überschrieben werden.
In der Spezifikation steht jedoch nichts von Nanosekunden [https://specifications.freedesktop.org/thumbnail-spec/latest/creation.html] Punkt 5.2.
Ist das jetzt ein Fehler?

frostschutz

Bei deinem Link (bzw. weiter unter Detect Modifications) steht sogar explizit daß nur auf die volle Sekunde aufgelöst wird ("one second resolution"). Bei meinem Thumbnailverzeichnis ist das auch so. Nur Thunar / tumbler scheint da anderer Meinung zu sein und klemmt da noch Zahlen hinters Komma.

Guckst du hier Use microsecond precision for last modification time

The time of last modification is stored internally in a `gdouble`, and
written to the PNG thumbnail in `%.6f` format. This complies well with
the Freedesktop specification [1], as the stat command returns this
format when invoked as `stat -c%.6Y file`, although it is likely that
the specification was written with the idea that this value be an
integer.

Also ganz lustig. Ja wir wissen daß die Spezifikation volle Sekunden meinte. Wir machens trotzdem anders.

frostschutz

Und damit entsteht ein unlösbares Problem. Es kann sein, daß viele Programme die hier in Integer erwarten, das Zeug hinterm . schlichtweg ignorieren. Es kann aber auch genausogut sein, daß andere Programme das schlicht als invalid ablehnen und ein neues Thumbnail erzeugen.

Genauso wie Thunar ein neues Thumbnail erzeugt, wenn der . fehlt (habe ich auf die Schnelle jetzt nicht getestet).

Wenn du also vorhast, eigene Thumbnails zu erzeugen, die dann nicht von anderen Programmen überschrieben werden. Das klappt dann schlicht nicht mehr weil du nicht beide Seiten gleichzeitig zufriedenstellen kannst.

Dakuan

Und damit entsteht ein unlösbares Problem.

Nicht ganz. Ich hätte da noch einen Holzhammer im Köcher. Aber ich war ja schon vor gewarnt, weil die ja auch bei den shared-thumbnails zuerst etwas anders gemacht hatten. Wobei man allerdings zugeben muss, das die ursprüngliche Formulierung bei freedesktop.org etwas schwammig war.
Die Holzhammermethode würde bedeuten, dass ich auch den Zeitstempel der Originaldatei so manipuliere, dass keine Nachkommastellen auftreten. Beim Übertragen über das Netzwerk, wo ich meinen eigenen Server als Sender Verwende, muss ich den Zeitstempel sowieso anpassen. Das ist auch der Grund, weshalb mir das erst jetzt aufgefallen ist.

Also ganz lustig. Ja wir wissen daß die Spezifikation volle Sekunden meinte. Wir machens trotzdem anders.

Das ist jetzt doppelt blöd. Denn ich hatte Thunar eigentlich nur deswegen installiert, weil ich testen wollte ob er mit meiner Interpretation von shared-thumbnails zurecht kommt (tut er) und ich keinen anderen Dateimanager kenne, der damit umgehen kann.

Wenn du also vorhast, eigene Thumbnails zu erzeugen, ...

Das mache ich seit über einem Jahr. Deshalb musste ich mich ja auch mit dem Problem auseinandersetzen, dass Thumbs nur eine begrenzte Lebensdauer haben und daher eine regelmäßige Auffrischung benötigen, falls man sie behalten will. Momentan zögere ich aber noch den Holzhammer raus zu holen. Wenn sich herausstellt, dass andere Dateimanager den Nachkommaanteil ignorieren, könnte ich den auch hinzufügen und alles ist gut.
Allerdings, wenn Thunar das einzige Programm ist, dass Nanosekunden angibt, ist das auch insofern schwammig, als da nur 6 Nachkommastellen verwendet weren. Die Funktion stat() liefert aber 9 Stellen (was aber wohl übertrieben ist). Mich stört nur, das es möglicherweise keine verbindlichen Vorgaben gibt (oder diese nicht beachtet werden?).

frostschutz

Dakuan Ja kannst du versuchen, ob Thunad fehlendes .000000 akzeptiert. Aber das wird dann umgekehrt Probleme machen mit deinen Backupprogrammen o.ä. die dann erstmal diese Dateien neu sichern werden. Die Datei zählt ja als modifiziert wenn du ihren Timestamp veränderst.

Scheinbar wurde das so eingeführt weil Thumbnails von "Dateien in Entstehung" erzeugt wurden, was zu defekten Thumbnails geführt hat, die dann auch später nicht mehr aktualisiert wurden weil der Timestamp ja immer noch aktuell war.

Aber wäre es da nicht einfach möglich gewesen, mit der Erzeugung des Thumbnails eine Sekunde zu warten? Wenn die Datei danach nochmal modifiziert wird, ändert sich der Timestamp ja wieder und damit gäbe es dann auch wieder den Thumbnail neu.

Irgendwie hat man da neue Probleme geschaffen nur um ein (seltenes) Problem zu umschiffen.

Ich nutze sehr wenig GUI und dementsprechend wird bei mir nur selten mal ein Thumbnail erzeugt. Aber wenn da jemand zwei verschiedene Programme aktiv nutzt und die überschreiben sich ständig gegenseitig ihre Thumbnails? Das ist doch Mist.

Dakuan

Thunar akzeptiert es, wenn die Nullen fehlen, erwartet dann aber auch bei der Originaldatei dass der Nachkommaanteil Null ist.

frostschutz Scheinbar wurde das so eingeführt weil Thumbnails von "Dateien in Entstehung" erzeugt wurden, was zu defekten Thumbnails geführt hat, ...

Der Fall kann eigentlich nicht eintreten. Ein Dateimanager sollte doch erst aktiv werden, wenn er die write-close Info bekommt. Und dann soll er auch erstmal prüfen, ob bereits gültige Thumbs vorhanden sind. Und wer ganz sicher gehen will, erzeugt die neue Datei mit einem temporären Namen, schreibt dann die Thumbs und macht dann ein rename. Hilft aber nichts, wenn Thunar es besser machen will.

Aber wenn da jemand zwei verschiedene Programme aktiv nutzt und die überschreiben sich ständig gegenseitig ihre Thumbnails?

Caja überschreibt die Thumbs nicht, das macht nur Thunar. Wahrscheinlich ist man davon aus gegangen, dass man normalerweise nur einen Dateimanager nutzt. Und selbst dann würde es meistens nicht auffallen, denn für Videodateien wird ja normalerweise ffmpegthumbnailer mit 10% der Laufzeit verwendet. Und bei Bilder fällt das sowieso nicht auf.
Wenn ich jetzt wüsste, dass andere Dateimanager den Nachkommaanteil auch ignorieren, könnte ich das auch einbauen, möglicherweise als Option.
Ist aber trotzdem ärgerlich und erzeugt zusätzliche Arbeit.

frostschutz

Kannst ja dein Glück mit einem Bugreport versuchen https://gitlab.xfce.org/xfce/tumbler/-/issues

Aber ob das nochmal jemand ändert über 3 Jahre später...

Dakuan

Ich glaube nicht, dass tumbler dafür verantwortlich ist. Die Thumbnailer liefern, soweit ich das bisher beobachtet habe, nur das Bild. Für die passenden Metadaten ist der Auftraggeber verantwortlich. In diesem Fall also Thunar oder ein Teil davon. Früher stand im Software Chunk der Vorschaudatei der Name "exo", in letzter Zeit ist das aber leer.
Im Grunde könnte man auch Screenshots verwenden und die passenden Metataten mittels exiftool einfügen. Das ist mühsam, zumal wenn dann "Sonderzeichen" noch URL-codiert werden müssen.

Dakuan

Ich muss dass nochmal los werden. Die Nanosekunden von Thunar, bei der Mtime, ist ein großes Ärgernis. Ich dachte, ich könnte mich darauf einstellen. Aber so einfach ist das nicht.

Mein Programm möchte z.B. auf eine smb oder ftp Freigabe zugreifen, wobei ich aber die entsprechenden Protokolle (noch) nicht installieren konnte (wollte?). Das bedeutet, ich muss über den alternativen Link zugreifen, den Filemanager oft bereitstellen:
/run/user/1000/gvfs/smb-share:server=lager1,share=homes/manfred/data/VIDEO.mp4
Dabei gibt es aber das Problem, dass ich nicht an die Nanosekunden ran komme. Alles was ich mache ergibt da Null. Wenn ich dann mit statfs den Dateityp abfrage, bekomme ich FUSE_SUPER_MAGIC. Das bedeutet dann wohl, dass noch Fuse dazwischen steckt. , und ich somit nur an die Daten herankomme, die Fuse durch reichen will.
Im Klartext bedeutet das, dass ich für Video Dateien auf einem externen Medium (z.B. über smb://) keine Nanosekunden bekommen kann, und somit fast alles was ich mache, von Thunar platt gemacht wird.
Falls jemand noch eine Idee hat, was ich da machen könnte, ohne smb, ftp oder ssh zu implantieren, her damit.
p.s.: Ich hatte Thunar hauptsächlich deswegen installiert, weil es der einzige, mir bekannte Dateimanager ist, der mit shared-thumbnails umgehen kann. Bei USB-Medien funktioniert das auch. Aber bei "smb.//" z.B. nicht. Dabei wäre gerade das der Anwendungsfall, wo es wirklich sinnvoll wäre.

tuxnix

Wie wär's mit nfs?
Das müsste eigentlich alles durchreichen wie es ist.

Dakuan

Sorry, habe das erst jetzt gesehen. War mit anderen Problemen beschäftigt.

Aber ich denke, wie das entfernte Dateisystem eingebunden wird ist ist nicht der Punkt. Denn Thunar kommt offenbar mittels smb:// an diese Daten heran. Ich habe auch ftp:// und ssh:// getestet. Das macht keinen Unterschied.

Der Punkt ist, dass Programme, die nicht selber das betreffende Protokoll implementiert haben, nur über einen alternativen Pfad zugreifen können, den z.B. ein Dateimanager bereit stellt. Also etwa über:
/run/user/1000/gvfs/smb-share:server=lager1,share=homes/manfred/
der aber eigentlich
smb://lager1/homes/manfred/data/
ist. Ich hatte ja auch schon erwähnt, dass meine Anwendung dann als Dateisysten fuse sieht.

Wenn ich Dateien mit meinem selbst gestrickten Programm übertrage, ist alles in Ordnung, da ich auf dem Ziel die MTime der Kopie auf die des Originals setze (aber die Nanosekunden nicht habe). Aber wenn ich einen Dateimanager dafür verwende, sind die Nanosekunden vorhanden.

Man könnte also sagen, fuse hält Daten zurück und Thunar übertreibt. Für mich bedeutet das, dass ich Thunar zukünftig vermeiden muss, was schade ist, da es bisher der einzig mir bekannte Dateimanager ist, der shared Thumbnails unterstützt (wobei das bei Netzwerk Devices nicht richtig funktioniert, nur USB geht).