nicht angemeldet
Re:
Scriptmeldungen bei error_reporting(2047); und einem GET-Request:
Notice: Undefined index: data in ~/speichern.php on line 177
Notice: Use of undefined constant show_html - assumed 'show_html' in ~/speichern.php on line 233
Notice: Undefined variable: filedata in ~/speichern.php on line 256
Notice: Undefined variable: filedata in ~/speichern.php on line 257
Notice: Undefined variable: filedata in ~/speichern.php on line 258
Notice: Uninitialized string offset: 0 in ~/speichern.php on line 264
Notice: Uninitialized string offset: 0 in ~/speichern.php on line 267
Notice: Uninitialized string offset: 0 in ~/speichern.php on line 270
Nach Anlegen der mit $filename und $lockfile benannten Datein sieht es immernoch meit einem GET-Request nun so aus:
Notice: Undefined index: data in ~/speichern.php on line 177
Notice: unserialize() [function.unserialize]: Error at offset 0 of 2 bytes in ~/speichern.php on line 161
Notice: Undefined index: btn in ~/speichern.php on line 203
Notice: Undefined index: btn in ~/speichern.php on line 209
Notice: Undefined index: data in ~/speichern.php on line 217
Notice: Use of undefined constant show_html - assumed 'show_html' in ~/speichern.php on line 233
Mit einem POST-Request über das Formular:
Notice: Undefined index: download in ~/speichern.php on line 203
Notice: Use of undefined constant show_html - assumed 'show_html' in ~/speichern.php on line 233
Notice: Undefined variable: meldung in ~/speichern.php on line 254
Also keine Warnung. Entschuldige - mein Fehler!
Als überaus ärgerlich habe ich auch den Fehler aus Zeile 298 <form action="/speichern.php" method="post"> emfpunden. Solche Flüchtigkeitsfehler wie auch show_html statt $show_html müssen in einem über ein halbes Jahr propagiertem Script nun wirklich nicht sein.
Was also bitte funktioniert nicht, was konntest Du feststellen?
Ich habe Dir die Frage mal so beantwortet, als hättest Du sie ernst gemeint...
Was ich noch vergessen hatte zu erwähnen: Es ist auf Linux getestet worden.Mit so einer dämlichen Reaktion auf ausdrücklich erbetene Verbesserungsvorschläge hätte ich von _Dir_ nicht erwartet! (bin stocksauer)
Man kann sich auch so seine Wahrheit zusammenkopieren
Versteh ich nicht. Ich habe doch auf Deutsch um Aufschluss gebeten, oder?
Den hatte ich Dir auf dämliche Deine Frage -was da was sei- auch gegeben, um Dir alle Möglichkeiten, ein gleiches Testsystem zu erstellen, mitzuteilen.
Und da ich nicht direkt auf den RAM (als shared Memory) zugreife, sehe ich auch keine Veranlassung, selber Semaphore einzuführen.
Schlichterdings funktioniert das Script nicht, das könntest Du schnell selbst testen. Für mich zumindest wäre dies hinreichender Grund eine Veranlassung zu sehen, über Semaphorenhandling zum Blocken der Speicherdatei zumindest nachzudenken.
Das IST Sache des Betriebssystems, dessen Funktionen PHP für flock() auch nutzt.
Ich hatte Dir nicht ohne Grund "RTFM" geschrieben. Die Dokumentation in Deutsch und Englisch sind sich in diesem mal Punkt erstaunlich einig:
Bei einigen Betriebssystemen ist flock() auf dem
Prozesslevel implementiert. Wenn Sie ein multi-
threaded Server API wie ISAPI benutzen können
Sie sich nicht auf flock() verlassen, um Datei-
en vor anderen PHP-Skripten zu schützen, welche
in parallelen Threads der gleichen Server-Instanz
laufen!
On some operating systems flock() is implemented
at the process level. When using a multithreaded
server API like ISAPI you may not be able to rely
on flock() to protect files against other PHP
scripts running in parallel threads of the same
server instance!
Nur wenn ich ans OS etwas dranstricke, was noch nicht funktionell durchkonzipiert ist, muss ich auf die Ebene der selbstgebauten Merker und deren Funktionen zurückgehen.
Erkläre Dich bitte! Was meinst Du mit diesem Wort? Nach meinem Test redest Du hier anscheined von flock(), da Semaphoren im Manual nicht als experimentell beschreiben und nach ersten Test von mir die Funktionalität sichern, wo flock() in _nicht funktioneller Konzeption_ verfehlt.
Wenn ich da jetzt irgendwas falsch verstanden habe, könntest Du es mir doch ganz sachlich erklären. Und was PHP mit einer ACCESS-Datenbank zu tun hat, ist mir auch nicht einsichtig.
Nichts - aber auch rein gar nichts; und ich bin mir sicher, Du weißt genau was gemeint ist.
Ich weiß jetzt jedenfalls immer noch nicht, was es zu bemängeln gibt?
Das Script arbeitet unter "Apache 2.0.53 (MPM worker; PHP als Handler 5.0.4)" auf Linux nicht korrekt. Aus der Passage des Scriptes...
Wenn kein ordnungsgemäßes Locking programmiert wurde, wird die
Zählerdatei nach dem Versuch zerstört sein, oder zumindest
mit einem erheblichen Fehler gezählt haben
...entnehme ich, das der Zweck ein ordnungsgemäßes Locking realisieren soll. Könnte der empfundene Mangel des "nicht korrekt arbeites" aus dem Verfehlen dieses Zweckes (ansich selbstredend) herrühren?
Welche Fehlermeldungen kommen denn?
Keine.
Auf meinen sämtlichen Testservern läuft das Script einwandfrei.
Diese laufen mit dem Prozessmodul worker?
Ich kann also nicht nachvollziehen, wo es kneift.
Das Script zeichnet sage und schreibe 946 Zugriffe beim Test mit "ab -n 1000 -c 10 [Resource]" und 245 beim Test mit "ab -n 1000 -c 100 [Resource]" auf; und das kneift dann schon!
Gruß aus Berlin!
eddi