PHP wird seine eigenen hochgeladenen temporären Dateien nicht bestätigen

9

Ich habe hier einen echten Kopf-Kratzer.

Dies ist meine Systemkonfiguration:

  • Windows Server 2008 R2
  • PHP 5.3.8 als FastCGI-Modul installiert
  • IIS 7.5

Das ist mein Problem:

Ich habe ein einfaches Datei-Upload-Formular. Wie wir wissen, wenn PHP einen Datei-Upload akzeptiert, erhält die Datei einen temporären Namen und wird vor ihrer Verarbeitung in ein temporäres Verzeichnis gestellt. In meinem Fall legt PHP die Datei in das temporäre Verzeichnis (das zufällig E: \ Inetpub_IIS \ tmp neben E: \ Inetpub_IIS \ wwwroot ist), vergisst dann aber sofort, dass die Datei existiert, bis der Garbage Collector erscheint. was die temporäre Datei löscht. Genauer gesagt, die temporäre Datei wird im temporären Verzeichnis auf dem Server erstellt, aber wenn ich sha1_file () für diese Datei aufruft, gibt die Funktion nichts zurück. file_exists () schlägt ebenfalls fehl. Das lässt mich denken, dass PHP die Datei nicht finden kann. Das folgende ProcMon-Protokoll zeigt, dass PHP an der richtigen Stelle sucht.

Hier ist mein ProcMon-Protokoll:

%Vor%

Wie Sie sehen können, zeigt ProcMon deutlich die temporäre Datei an, die erstellt, geschrieben und dann geschlossen wird. Kurz vor dem Ende können Sie die "QueryDirectory" -Aufrufe sehen, die mit meinen Skriptaufrufen übereinstimmen, die unter anderem versuchen, den SHA1-Hash der Datei zu erhalten.

Das ist mein Skript:

Das Datei-Upload-Formular enthält ein Flash-Objekt und einige DIVs für das Flash-Objekt, um das Formular zu erstellen, nicht mehr. Die temporäre Upload-Datei wird auf dem Server in seiner Gesamtheit erstellt, so dass ich sehr ernst bezweifle, dass mein Formular das Problem ist.

%Vor%

Der Inhalt von "logfile.txt":

%Vor%

Der "Schlaf" -Aufruf gibt mir Zeit, das temporäre Verzeichnis für die Datei zu überprüfen, bevor sie verschwindet.

Dutzende von Google-Suchen haben mich zu Dingen geführt, die die Berechtigungen betreffen, oder zu Lösungen, bei denen hochgeladene Upload-Formulare fehlen, die überhaupt nichts hochladen. Die Dateien werden auf dem Server erstellt, so dass das Formular funktioniert. Außerdem habe ich versucht, IUSR, IIS_ISURS und DefaultAppPool vollen Zugriff auf das temporäre Verzeichnis und auf E: \ Inetpub_IIS zu geben, um zu sehen, ob dies etwas mit den zugehörigen Berechtigungen zu tun hat, aber das nichts geändert hat. Kann mir jemand Ratschläge geben, was hier vor sich geht?

BEARBEITEN: Ich habe es herausgefunden.

DaveRandom und ich dachten beide, dass es sich um ein Berechtigungsproblem irgendeines Typs handelte, was richtig war. Wir dachten jedoch beide an Windows-Berechtigungen, als das Problem tatsächlich ein PHP-Erlaubnis- / Konfigurationsproblem war. Daves "Arbeit rückwärts" -Phrasierung brachte mich dazu, rückwärts durch den Verzeichnisbaum zu gehen und Berechtigungen zu testen, die schließlich die folgende Lösung hervorbrachten.

Was ich getan habe:

Ich habe ein sehr kurzes Skript geschrieben:

%Vor%

Dies hat FALSE zurückgegeben. Anscheinend war das Verzeichnis nicht lesbar, wie Dave vorgeschlagen hat.

Ich habe das Verzeichnis E: \ Inetpub_IIS \ wwwroot ausprobiert, das TRUE zurückgegeben hat. Hmm. Ich erkannte dann, dass ich den php_error.log den ganzen Tag nicht überprüft hatte. Hier ist, was ich gefunden habe:

%Vor%

Ich googelte "open_basedir Einschränkung in Wirkung" und hatte meine Antwort. In der Datei php.ini wurde open_basedir auf:

gesetzt %Vor%

Ich habe das geändert zu:

%Vor%

Nach dem Neustart des Servers begann die App wie beabsichtigt zu arbeiten.

Hoffentlich ist das genug Dokumentation für jemand anderen, der das gleiche Problem haben könnte.

Moral (s) der Geschichte:

  • Überprüfen Sie Ihre Einstellung für open_basedir.
  • Aktivieren, einstellen und vergessen Sie nicht, Ihr PHP-Fehlerprotokoll zu überprüfen.
  • Betrachte das gleiche Problem 7 Stunden lang nicht ohne Pause. Ich glaube, ich hatte fast einen Schlaganfall.
TPC 27.12.2011, 21:15
quelle

1 Antwort

4

Wie versprochen, hier ist meine Antwort. Dies wurde kopiert / eingefügt von der OP-Bearbeitung.

Ich habe es herausgefunden.

DaveRandom und ich dachten beide, dass es sich um ein Berechtigungsproblem irgendeines Typs handelte, was richtig war. Wir dachten jedoch beide an Windows-Berechtigungen, als das Problem tatsächlich ein PHP-Erlaubnis- / Konfigurationsproblem war. Daves "Arbeit rückwärts" -Phrasierung brachte mich dazu, rückwärts durch den Verzeichnisbaum zu gehen und Berechtigungen zu testen, die schließlich die folgende Lösung hervorbrachten.

Was ich getan habe:

Ich habe ein sehr kurzes Skript geschrieben:

%Vor%

Dies hat FALSE zurückgegeben. Anscheinend war das Verzeichnis nicht lesbar, wie Dave vorgeschlagen hat.

Ich habe das Verzeichnis E: \ Inetpub_IIS \ wwwroot ausprobiert, das TRUE zurückgegeben hat. Hmm. Ich erkannte dann, dass ich den php_error.log den ganzen Tag nicht überprüft hatte. Hier ist, was ich gefunden habe:

%Vor%

Ich googelte "open_basedir Einschränkung in Wirkung" und hatte meine Antwort. In der Datei php.ini wurde open_basedir auf:

gesetzt %Vor%

Ich habe das geändert zu:

%Vor%

Nach dem Neustart des Servers begann die App wie vorgesehen zu funktionieren.

Hoffentlich ist das genug Dokumentation für jemand anderen, der das gleiche Problem haben könnte.

Moral (s) der Geschichte:

  • Überprüfen Sie Ihre Einstellung für open_basedir.
  • Aktivieren, einstellen und vergessen Sie nicht, Ihr PHP-Fehlerprotokoll zu überprüfen.
  • Betrachte das gleiche Problem nicht für 7 Stunden. Ich glaube, ich hatte fast einen Schlaganfall.
TPC 28.12.2011 15:56
quelle

Tags und Links