On Mit, 18 Jul 2001, Bernd Brodesser wrote:
* David Haller schrieb am 18.Jul.2001:
On Die, 17 Jul 2001, Bernd Brodesser wrote:
* David Haller schrieb am 17.Jul.2001:
On Mon, 16 Jul 2001, Jan Trippler wrote:
On Mon, 16 Jul 2001 at 19:39 (+0200), David Haller wrote:
tmp_datei="`mktemp /tmp/${prg}.$$.XXXXXX`" || exit 1
Wenn es nicht funktioniert, dann sollte da aber schon eine Fehlermeldung kommen. Kommt doch sonst nie einer drauf, daß es an der Nichtanlegbarkeit (was für ein Wort ;)) der Tempdatei liegt.
Hast du's getestet? Das ist naemlich Absicht, dass da nur das exit 1 steht:
$ mktemp /root/${prg}.$$.XXXXXX Cannot create temp file /root/.12760.YTRUBd
Ich mache meine Fehlermeldung lieber selber. Was soll der Endanwender mit obiger Meldung anfangen?
Du weisst ja auch nix genaues (Rechte, Disk voll, uebergeordnetes Verz. existiert nicht)... Du weisst du dass es nicht geklappt hat (mkstemp liefert nur 1 als exit-status). Allerdings habe ich gesehen, dass die originale Version von mktemp durchaus auch strerror(errno) ausgibt, das hat der patch (-linux.patch) eben ueberschrieben.
Der weiß doch gar nicht was ein tempfile ist. Auch hier ist perl flexiebler.
Das mag sein. Und ich denke die beste Loesung ist eh, die Meldung von mktemp (samt strerror(errno) wg. dem Grund, s.o) auszugeben, und dann zusaetzlich evtl. noch eine eigene... Aber das haengt natuerlich auch stark von dem Umstaenden ab, in denen die temporaere Datei benoetigt wird...
Das $$ ist hier eigentlich nicht mehr nötig. mktemp macht einen Einzigartigen Namen.
Naja, "einzigartig" halt im Rahmen von mkstemp... Und "sicher" ist die in mkstemp verwendete Funktion __gen_tempname nicht...
Mist. Habe ich nicht ausprobiert. Ich kannte mktemp bisher nur so, daß es a$$.tmp oder so ähnlich ausgab. Sollte genau dies schon existieren, so gab es b$$.tmp aus usw. Halte ich für viel vernünftiger.
Nein, mktemp macht mittels der libc-Funktion 'mkstemp' (siehe die manpage dazu), aus "VORLAGEXXXXXX" ein "VORLAGEZZZZZZ" wobei ZZZZZZ das generierte "eindeutige" Muster ist (aus a-z A-Z 0-9). mkstemp wiederum verwendet die (libc-interne) posix-funktion __gen_tempname um aus das sechststellige Muster zu erzeugen, mit dem das XXXXXX in der Vorlage ersetzt wird.
Wichtig ist doch, daß mktemp überprüft, ob der vorgeschlagene Dateiname schon existiert oder nicht. Wenn es das nicht tut, dann ist es nicht zu gebrauchen.
Tut es. Es scheitert dann (bzw. mkstemp(3) scheitert und gibt in errno EEXIST ("File exists" bzw. "Die Datei existiert bereits") zurueck. Leider gibt die gepatchte Version von mktemp diese Fehler- ursachen weder aus noch weiter (z.B. mittels 'exit(errno);')...
Dabei benutze ich mktemp mehrfach. Ich sollte mir mal die Tempfiles angeschaut haben. ;) Hmm, in einen Fall, habe ich es sogar recht häufig gemacht, aber nicht auf dem Namen geachtet. Der $0-Bestandteil hatte zum Auffinden gereicht. ;))
*g*
Dann schlage ich sowas wie
${prg}.`date +%s`.$$.tmp vor. Da gibt es so schnell keine doppelte, es sei denn es werden im Prozeß selber mehere tmp angelegt. Die kann ich dann aber hart anders nennen, etwa:
$TMP1=$TMPDIR/$PRG.A`date +%s`.$$.tmp $TMP2=$TMPDIR/$PRG.B`date +%s`.$$.tmp $TMP3=$TMPDIR/$PRG.C`date +%s`.$$.tmp
Sollte man in einer Schleife Tempdateien anlegen (könnte ja sein, daß man das braucht. ;)) dann wird der Schleifenzähler mit im Namen aufgeführt.
Ack.
Kryptographisch "sicher" ist das IMO nicht.
Was hat das mit Kryptographie zu tun? Auch wenn es echte Zufallszahlen sind, wird Gleichheit nicht ausgeschlossen.
Naja, um die Gleichheit geht es auch nicht (es gibt fuer das Muster immerhin 62^6 = 56.800.235.584 Moeglichkeiten). Das Problem ist, wie das Muster erzeugt wird (d.h. mit welchem Aufwand es zu vorherzusagen ist...) Und da ist das "clevere" Schema das in __gen_tempname verwendet wird nicht sonderlich, Es heisst: ==== /* Get some more or less random data. */ __gettimeofday (&tv, NULL); value += ((uint64_t) tv.tv_usec << 16) ^ tv.tv_sec ^ __getpid (); ==== d.h. es wird die Zeit (theoretisch auf die Mikrosekunde) genau und die PID verwurstet. Allerdings sind beide Datenquellen nicht als "zufaellig" einzustufen. Die PID laesst sich sowieso leicht heraus- finden und die Zeit, zu der das __gettimeofday() aufgerufen laesst, laesst sich (vermute ich) mit tests ebenfalls (hinreichend) genau vorhersagen. Das restliche Verwursten dieser Daten ist dann einfach. Besser waere es wohl, sich die 64 bit Daten aus /dev/random zu besorgen, aber /dev/random ist halt (AFAIK) nicht im POSIX Standard... (Siehe dazu /usr/src/linux/drivers/char/random.c (den Anfangskommentar) und man 4 random). Das "sicher" bezieht auf die Vorhersagbarkeit... Wolfgang koennte zu den Folgen der (von mir vermuteten Vorhersagbarkeit) noch einiges mehr sagen... Aber wie gesagt, ich denke, dass die (Nicht-)Vorhersagbarkeit von __gen_tempname (und somit von mkstemp(3) und mktemp(1)) fuer die meisten Faelle ausreicht (also schwierig genug ist)...
Was mir an Deiner trap-Zeile auffällt, Du fängst Signal 14 nicht ab.
Oh, das war nur kurz hingeschludert, SIGALRM hab ich schlicht uebersehen ;) -dnh --
Blame directed at the wrong vendor tends to get reclassified as whining. No worries, I'm good at that too. -- Chris Hacking and Jay Mottern in asr