nicht angemeldet
Fein. Der Upload ist inzwischen möglicherweise fertig. Vielleicht auch nicht. Nur: Eine Kontrolle irgend einer Art hast Du darüber nicht.
Doch. In diesem Falle ist das Tempfile, das PHP _definitv_ erzeugt entweder nicht mehr gelockt (Upload ist beendet, aber das entgegennehmende Script ist noch nicht abgelaufen) oder nicht mehr existent, da es nach Ablauf des Scriptes, das vom Upload-Form aufgerufen wurde, gelöscht wird.
Wie kommst Du darauf, daß der Upload eine temporäre Datei verwendet?
1. Es steht im Manual.
2. PHP übergibt dem Script, das den Upload entgegennimmt, den entsprechenden temporären Dateinamen.
Das Ziel des "Upload" ist ja nicht, eine Datei auf dem Server zu erzeugen. Das Ziel ist, es auf dem Server eine Anwendung zu starten, welche den Inhalt eines CGI-Multipart-Pakets als Parameter erhält.
Genau. Im Falle von PHP wird der entsprechende Part eben als temporäre Datei übergeben, d.h. PHP sorgt dafür, dass ein Teil der ankommenden body-Daten des Requests in ebenjener Datei landet.
* Gibt es eine Möglichkeit, den Namen des Tempfiles (in Verbindung mit einer Session) im Voraus festzulegen, ohne am PHP Interpreter herumzubosseln?
Nein. Weder existiert eine solche Datei unbedingt
Siehe oben...
noch erlaubt Dir HTTP, darauf in irgend einer Weise Einfluß zu nehmen.
Hm, ich war wohl etwas undeutlich. Also noch einmal: Es geht - zumindest in dieser Frage - um die Realisierung der im Subject genannten Aufgabe in _PHP_. Und damit kann ich auf einiges Einfluss nehmen (entsprechende Rechte vorausgesetzt).
* Gibt es eine Möglichkeit, die id des http-Prozesses des Uploads herauszubekommen und darüber das File zu indentifizieren?
Du gehst immer noch davon aus, daß der Upload etwas sei, was er nicht ist. Passe Deine Vorstellung der Realität an.
Könntest Du das präzisieren?
Meine Vorstellung vom Vorgang des Multipart-Requests ist es, dass es auf alle Fälle einen Server-Prozess gibt, der den Request und die zugehörigen Daten entgegennimmt. Dieser Prozess reicht die Daten an die im Request genannte Anwendung bzw. deren Handler - in diesem Falle den PHP Interpreter - weiter. Dieser wiederum erkennt, dass der Request im body Daten enthält und speichert diese in einer temporären Datei zwischen, um deren Namen an das aufgerufene Script zu übergeben, sobald die Daten komplett angekommen sind und der Parser mit der Abarbeitung des Scriptes beginnt.
Etwas Anderes ist es, wenn Du Dein Modell in mehrere Requests zerlegen könntest.
Erst lesen, dann posten. Ich zitiere mich mal selbst: "Also wird per onsubmit ein zweites Script aufgerufen[..]". Das _ist_ ein zweiter Request.
Du könntest also _theoretisch_ folgendes versuchen:
[..]
Nichts anderes habe ich bereits beschrieben, wenn auch nicht so ausführlich.
Wäre JavaScript eine "richtige" Programmiersprache, dann könnte es sogar einen HTTP-HEAD-Request auf die entstehende Datei senden - [..]
Es geht hier um PHP. Mir ist schleierhaft, wieso dieser Thread in der Rubrik "HTTP" fortgesetzt wird. Die einzige Stelle, an der Javascript vorkommt, ist das Auslösen des zweiten Requests. Natürlich muss das Tracing serverseitig ablaufen, denn dort passiert ja das, was ich tracen möchte.
[..]Parametern berechnen können, wie die zu erstellende Datei auf dem Server heißen wird.
Nach eben diesen Parametern habe ich gefragt. Nach nichts anderem, denn der Rest ist trivial.
a) einen prozentualen Anteil der Übertragung. Niemand weiß nämlich, wie groß die Datei am Ende sein wird. Zustandsbalken etc. entfallen also.
Der HTTP-Request enthält in der Regel einen Content-Length Header, der von den üblichen Browsern bei Multipart-Daten IMHO auch mitgeschickt wird. Probleme gibt es u.U. damit, von einem paralellen Prozess aus auf diese Daten zuzugreifen ohne root-Rechte zu haben.
b) ein zuverlässiges Ende der Übertragung. Wenn sich der Zustand der Datei nicht mehr ändert, dann kann das Upload-Script vielleicht nur eine Pause machen.
Im Regelfall sind solche Dateien offen, d.h. sie haben ein entsprechendes locking, das sich auch abfragen lässt. Davon abgesehen gibt es ein eindeutiges Signal für einen abgeschlossenen Multipart-Request, da dann mit der Abarbeitung des Scriptes begonnen wird und dieses (z.B. über Shared Memory oder Semaphore) dem zweiten Script (also dem Tracer) Bescheid sagen kann.
P.S.: Vielleicht fällt Dir auf, daß meine Ausführungen keinerlei Erwähnung einer bestimmten serverseitigen Programmiersprache enthielten.
Das ist mir allerdings aufgefallen, aber was sagt mir das? Genau darauf bezog sich meine Frage, weswegen dieser Thread von mir auch unter der Rubrik "PHP" begonnen wurde und nicht unter "HTTP". Keine Ahnung, wie der hierher geraten ist - war da der Forumsgeist am Werk?
regards,
Andreas