Problem mit Dateien in /tmp/

[dakuan]

Ich habe da ein Programm gebastelt, das die Ausgabe von ffmpeg benötigt (nur 1 frame) und dies in /tmp/ ablegt, wo mein Programm dann das Ergebnis abholt. Das funktioniert im Pronzip ganz gut und ich muss mich nicht um die Entsorgung kümmern.

Jetzt habe ich aber mehrere Benutzer auf meinem System und nach einem Benutzerwechsel gibt es dann natürlich Probleme, weil der Dateiname immer gleich ist. Der andere Benutzer kann die temporäre Datei nicht löschen/überschreiben da er nicht der Eigentümer ist. Im Home Verzeichnis des Benutzers wollte ich die Datei jetzt auch nicht anlegen lassen, da ich mich dann ja auch um die Entsorgung nach Programmende kümmern muss.

Wie kann ich das Problen noch lösen?

[JTH]

Wie du merkst, sollte man für temporäre Dateien & Ordner nie fix festgelegte Namen benutzen.

Du kannst dir mit mktemp (in Skripten) oder mkstemp (C, andere Sprachen haben Äquivalentes) temporäre Dateien oder Ordner mit garantiert eindeutigem Namen anlegen.

[Meillo]

Wie du merkst, sollte man für temporäre Dateien & Ordner nie fix festgelegte Namen benutzen.

Du kannst dir mit mktemp (in Skripten) oder mkstemp (C, andere Sprachen haben Äquivalentes) temporäre Dateien oder Ordner mit garantiert eindeutigem Namen anlegen.

Dann muss der Dateiname aber vom einen zum anderen Programm transportiert werden. Mir scheint, bislang wird das dadurch geloest, dass in beiden Programmen ein fixer Dateiname hardcoded ist.


Da das selbstgeschriebene Script den zweiten Prozessschritt darstellt, kann man die Datei doch darin explizit loeschen. Dann hat man das Problem des Aufraeumens doch unter Kontrolle und braucht /tmp nicht dafuer, oder?


Du koenntest die Dateien auch mit einem Namen in der Art von:

Code: Alles auswählen

/tmp/foo-`id -u`-$$

anlegen und dann so die neueste Datei des Users ermitteln:

Code: Alles auswählen

ls -t /tmp/foo-`id -u`-* | head -n 1

(Oder ohne die Prozessnummer ($$), dann ist es genau eine Datei pro User.)

... oder kann man bei ffmpeg als Ausgabedatei nur einen Fixstring angeben?

[heinz]

...dann ist es genau eine Datei pro User.

Waere es dann nicht einfacher die Variable $USER zu verwenden?

Code: Alles auswählen

/tmp/${USER}_foo

Oder existiert diese nicht immer?

[MSfree]

...und ich muss mich nicht um die Entsorgung kümmern.

Das ist ein Trugschluß. Wenn kein Cron-Job dafür sorgt, daß dort alte Dateien gelöscht werden, stehen die bis zum Sanktnimmerleinstag dort. Programme, die Dateien in /tmp anlegen, müssen sich also auch um ihre Ensorgung kümmern.

[Meillo]

...dann ist es genau eine Datei pro User.

Waere es dann nicht einfacher die Variable $USER zu verwenden?

Code: Alles auswählen

/tmp/${USER}_foo

Oder existiert diese nicht immer?

Eine Variable ist besser als die Befehlssubstitution. ($LOGNAME ist vielleicht etwas portabler als $USER.)


@MSfree: Wie meinst du das? Auf einem Desktop-System, das regelmaessig neu gebootet wird, wird /tmp doch immer wieder geleert. Schoen ist das nicht unbedingt, aber man kann so arbeiten. Nur wenn der regelmaessige Reboot fehlt ist man gezwungen selbst aufzuraeumen.

Wobei mir das im Falle einer einzigen Datei fixen Namens wie ein akademisches Problem vorkommt. Was muss da denn ueberhaupt aufgeraeumt werden, wenn das Programm genau eine Datei anlegt und beim naechsten Mal ueberschreibt. Da ist ein Aufraeumen insgesamt doch gar nicht noetig, weil der Speicherverbrauch konstant ist.

Ich denke, ich wuerde das Problem vielleicht so loesen, dass ich die Datei einfach unter ~/.ffmpeg-frame anlegen wuerde, dann hat jeder User seine eigene und als unsichtbare Datei stoert die im Homeverzeichnis auch nicht mehr oder weniger als in /tmp.

[MSfree]

@MSfree: Wie meinst du das? Auf einem Desktop-System, das regelmaessig neu gebootet wird, wird /tmp doch immer wieder geleert.

Richtig, aber auf Servern, die nur alle Jubeljahre mal gebootet werden, sammeln sich Dateien unter /tmp eben an. Ich mußte nämlich gerade selbst feststellen, daß auf meinem Heimserver noch Dateien vom Februar 2020 rumklungern.

Besonders unschön ist das, wenn /tmp als tmpfs (also RAM-Disk) eingehängt ist. Dann verstopft man mit der Zeit seinen Hauptspeicher und wundert sich, warum die Kiste elendig swapt.

Dazu kommt noch der Datenschutzaspekt. Ich halte es für keine gute Idee, potentiell persönliche Daten dort abzulegen und sich darauf zu verlassen, daß das System die schon irgendwann vielleicht mal aufräumen wird.

Wobei mir das im Falle einer einzigen Datei fixen Namens wie ein akademisches Problem vorkommt. Was muss da denn ueberhaupt aufgeraeumt werden, wenn das Programm genau eine Datei anlegt und beim naechsten Mal ueberschreibt.

Ich halte es für schlechten Programmierstil, das System, die Platte, die RAM-Disk, mit Dateien zu beschreiben und sie einfach stehen zu lassen, wenn man sie nicht mehr braucht. Nur, weil man zu faul ist, sich eine saubere Lösung auszudenken.

[Meillo]

@MSfree: Wie meinst du das? Auf einem Desktop-System, das regelmaessig neu gebootet wird, wird /tmp doch immer wieder geleert.

Richtig, aber auf Servern, die nur alle Jubeljahre mal gebootet werden, sammeln sich Dateien unter /tmp eben an. Ich mußte nämlich gerade selbst feststellen, daß auf meinem Heimserver noch Dateien vom Februar 2020 rumklungern.

Besonders unschön ist das, wenn /tmp als tmpfs (also RAM-Disk) eingehängt ist. Dann verstopft man mit der Zeit seinen Hauptspeicher und wundert sich, warum die Kiste elendig swapt.

Dazu kommt noch der Datenschutzaspekt. Ich halte es für keine gute Idee, potentiell persönliche Daten dort abzulegen und sich darauf zu verlassen, daß das System die schon irgendwann vielleicht mal aufräumen wird.

Dann habe ich den Hintergrund deiner Aussage richtig verstanden. Ja, so sehe ich das alles auch.

Wobei mir das im Falle einer einzigen Datei fixen Namens wie ein akademisches Problem vorkommt. Was muss da denn ueberhaupt aufgeraeumt werden, wenn das Programm genau eine Datei anlegt und beim naechsten Mal ueberschreibt.

Ich halte es für schlechten Programmierstil, das System, die Platte, die RAM-Disk, mit Dateien zu beschreiben und sie einfach stehen zu lassen, wenn man sie nicht mehr braucht. Nur, weil man zu faul ist, sich eine saubere Lösung auszudenken.

Ich finde es schwer, hier pauschale Bewertungen zu machen. Natuerlich, wenn eine Vielzahl von Scripten jeweils eine Datei anlegt, die dann ewig nicht mehr oder vielleicht auch nie mehr gebraucht wird, dann finde ich das auch schlecht. Ebenso finde ich es schlecht wenn das nur die Folge von Sorglosigkeit ist. Anders sieht es aus, wenn die Datei die Kommunikationsbasis eines regelmaessigen Datentransfers ist, bei dem zwei Programme ggf. asynchron eine Datei Schreiben und Lesen. Manchmal finde ich es sauberer eine fixe Datei zu haben und diese zu ueberschreiben als sie jedes Mal zu entfernen und neu anzulegen. Beispielsweise kann ich dann da letzte Bild mehrfach und mit verschiedenen Tools anschauen, ohne es immer wieder neu generieren zu muessen. Fuer mich kommt es auf das konkrete Szenario an, was ich sinnvoller finde.

[MSfree]

Anders sieht es aus, wenn die Datei die Kommunikationsbasis eines regelmaessigen Datentransfers ist, bei dem zwei Programme ggf. asynchron eine Datei Schreiben und Lesen.

Eigentlich hat man dafür doch /var/run, und Daten tranferiert man in so einem Fall über named Pipes. Die brauchen, abgesehen von einer inode, auch keinen Platz im Dateisystem.

Manchmal finde ich es sauberer eine fixe Datei zu haben und diese zu ueberschreiben als sie jedes Mal zu entfernen und neu anzulegen.

Das klappt halt nicht, wenn mehrere Prozesse diese Datei gleichzeitig beschreiben wollen und ein lesender Prozeß dann immer mal halbfertige Dateiinhalte zu sehen bekommt. Am Ende hat man ein Synchronisationsproblem, das man mit named Pipes von vorn herein hätte vermeiden können. Aber das führt ja dann schon weit weg von meinem Einwurf, daß man sich auch unter /tmp Gedanken machen sollte, aufzuräumen, wenn die Prozeßkette abgeschlossen ist.

[JTH]

Dann muss der Dateiname aber vom einen zum anderen Programm transportiert werden.

Ja, natürlich. Weil im ersten Beitrag aber nur abstrakt ein „gebasteltes Programm“ erwähnt ist, hab ich einfach die üblichen Möglichkeiten vorgeschlagen.

Mir scheint, bislang wird das dadurch geloest, dass in beiden Programmen ein fixer Dateiname hardcoded ist.

Dann würd ich zumindest ein mktemp -d als Ausgabeordner nehmen. Wenn wirklich der ganze Pfad hardkodiert ist, bekommt der Entwickler eine freundliche Nachricht

Du koenntest die Dateien auch mit einem Namen in der Art von:

Code: Alles auswählen

/tmp/foo-`id -u`-$$

anlegen und dann so die neueste Datei des Users ermitteln:

Code: Alles auswählen

ls -t /tmp/foo-`id -u`-* | head -n 1

(Oder ohne die Prozessnummer ($$), dann ist es genau eine Datei pro User.)

Auch eine Möglichkeit, je nach Anwendung. Aber wieder womöglich fragil, wenn ein Benutzer das Ganze irgendwann doch zweimal gleichzeitig startet. Ich gehe an solchen Stellen immer gerne gleich ganz auf Nummer sicher Man selbst oder Kollegen kommen sonst garantiert irgendwann auf die Idee, den gerade nicht vorgesehenen Fall auszuprobieren.

[dakuan]

Danke. Da sind jetzt mehr Antworten gekommen, als ich dachte. Die muss ich nochmal im Detail durcharbeiten.

Das mit mkstemp() hätte ich eigentlich wissen können. Aber bisher gefällt mit die Idee, die User ID in den Dateinamen einzubauen am besten.

Aber ich sehe auch, dass jeder eine andere Vorstellung von dem hat, was ich da mache. Also mit dem "entsorgen" hatte ich wohl etwas übertrieben. Der Dateiname ist immer gleich und die Datei wird jedesmal gelöscht bevor ffmpeg gestartet wird. ffmpeg fragt sonst jedes Mal, ob die Datei überschrieben werden soll.

Und das ganze ist kein Script sondern ein C++ Programm. ffmpeg wird da über fork() und execvp() gestartet.

Und so ganz hart codiert ist das auch nicht alles, denn der Dateiname und die Schablone für die Kommandozeilen kommen aus einer Konfigurationsdatei.

An das Thema "Datenschutz" hatte ich in diesem Zusammenhang überhaupt noch nicht gedacht. Aber bei Bildchen im Format 128x72 ist das wohl nicht wirklich kritisch.

Also das Programm zweimal zu starten macht für einen User nicht unbedingt Sinn, aber dann wäre vielleicht die Prozess ID zu verwenden eine bessere Idee.

[MSfree]

An das Thema "Datenschutz" hatte ich in diesem Zusammenhang überhaupt noch nicht gedacht. Aber bei Bildchen im Format 128x72 ist das wohl nicht wirklich kritisch.

Meinst du wirklich, daß man die abgebildete Person nicht erkennt?

[wanne]

@MSfree: Das scheint ein Bild von gettyimages zu sein. Die verkaufen Bilder an die Presse und mahnen auch sehr aktiv durch die allseits bekannte Kanzlei Waldorf Frommer zu regelmäßig absurd hohen Preisen ab. Ich habe das Bild entsprechend entfernt. (Wenn du die rechte am Bild wirklich hast, kannst du es wieder rein stellen.) Sonst mache ich ein anderes Foto. Der Playboy war so nett da ein Demobild genau für solche Zwecke bereitzustellen.

[MSfree]

@MSfree: Das scheint ein Bild von gettyimages zu sein.

Entschuldigung, da hatte ich nicht drauf geachtet. Ich wollte auch keinen in Schwierigkeiten bringen.

Ich wollte zum Ausdruck bringen, daß man menschliche Gesichter sehr wohl auf Bildern mit nur 128x72 Pixel erkennen kann. Ja sogar auf nur 32x32 Pixel kann man Gesichter noch erkennen, das Gehirn ist erstaunlich gut in der Mustererkennung.

[wanne]

Hier zwei freie Beispielbilder mit ungefähr128x72 Pixel.
Einmal gemacht vom Weißen Haus. Die Veröffentlichen immer nett Gemeinfrei:

Und einmal das bekannte Bild von Lenna aus dem Playboy:

Man erkennt sofort wer darauf zu sehen ist. Und das obwohl die Personen recht klein im Bild sind. Und das war noch der dumme biliniare Skalierungsalgorithmus. Das lässt sich eigentlich noch deutlich schöner hinbekommen.

Btw. Wann lernt die Galerie Webp und das Forum Image resizes ?

[dakuan]

Ich habe mich jetzt entschlossen das folgendermaßen zu ändern.

Dateiname und Pfad werden in der Konfigurationsdatei festgelegt. Voreingestellt ist dann so etwas:

Code: Alles auswählen

$HOME/.name$UID.png

Außerdem soll die Datei bei Programmende gelöscht werden. Das mit der User-ID geht schon, Für den Rest muss ich noch einiges umbauen.