in eigener classe mache ich im destructor serialisieren von einer lokaler Variable und speichere das in eine datei und kontrolliere sogar ob die datei wirklich gespeichert ist.
im konstruktor kontrolliere ich ob diese datei mit serialisierem Inhalt da ist, und im fall, dass die datei existiert unserialisiere der inhalt und speichere es in lokale Variable.
Mein Problem liegt aber daran, dass der konstruktor die Datei nie findet,(auch bei 2-tem reload von dem script) obwohl im destruktor sie generiert und für testzwecke mit file_get_contents ausgelesen wurde.
Die Datei muss doch bei dem zweitem aufruf von dem Object, wenn ich reload mache schon da sein:confused:
was dabei komisch ist, dass ich die datei mit explorer auch nicht finden kann :confused:
vielleich habe ich einfach problem an betrieb System?
Aber ich will besser hoffen, dass ich ein logisches problem habe.
System Windows XP, xamp mit php 5.1.4

der script:

error_reporting(E_ALL);
class Configuration{
private $file='./serialconfig.php';
private $werte;
public function __construct()
{
$this->werte=array();
if(file_exists($this->file)) //<-muss doch bei 2-tem aufruf da sein, schau destruktor.
{
$s=file_get_contents($this->file);
$this->werte=unserialize(base64_decode($s));
}else echo __LINE__.")file $this->file nicht gefunden<br />";//<-das bekomme ich ständig
}
public function getAll(){return $this->werte;}
public function __isset($var){return isset($this->werte[$var]);}
public function __set($was,$wert){ $this->werte[$was]=$wert;}
public function __get($was){return $this->werte[$was];}
public function __unset($var)
{
if(isset($this->werte[$var]))unset($this->werte[$var]);
}
public function __destruct()
{
echo "<br /> start von destruct <br />";
$s=base64_encode(serialize($this->werte));
//echo $s;
file_put_contents($this->file,$s);
if(file_exists($this->file))//hier habe ich extra zur kontrolle geprüft ob die datei geschrieben wurde
echo "<br />".__LINE__.")file $this->file existiert, Inhalt:".file_get_contents($this->file);
echo "<br />".__LINE__.")ende von destruct";
}
}

//Test
$con =new Configuration();//hier bekomme ich ständig meldung, dass die datei nicht existiert
$con->wartung='hallo';
echo $con->wartung;
//und hier kommt der destructor mit der bestätigung, dass die datei existiert.


die ausgabe auch bei mehrfachem reload (sogar mit verschiedenen get-parameter)
--------------------------------
58)file ./serialconfig.php nicht gefunden
hallo
start von destruct

75)file ./serialconfig.php existiert, Inhalt:YToxOntzOjc6IndhcnR1bmciO3M6NToiaGFsbG8iO30=
76)ende von destruct
----------------------
ich kann komische weise kein Grund finden, warum die datei im constructor nie gefunden wird und warum sie nicht auf der festplate zu finden ist, obwohl ich sie im destructor extra mit file_get_contents auslese.

ich kann ehrlich gesagt auch keinen Fehler finden...

was passiert denn, wenn du im selben script (ohne reload) zwei instanzen hintereinander erzeugst und zerstörst?

ungefähr so:


//Test
$con =new Configuration();//hier bekomme ich ständig meldung, dass die datei nicht existiert
$con->wartung='hallo';
echo $con->wartung;

unset($con); //altes con sollte hier zerstört werden

$con2=new Configuration(); //wird hier die datei gefunden??



bin jetzt etwas ratlos...

greetzm high

Wenn das alles in einem Scriptdurchlauf passiert, hilft dir:
http://de.php.net/manual/de/function.clearstatcache.php

*edit*
Dein Pfad wird nicht stimmen, so gehts:

class Configuration{
private $file='';
private $werte;
public function __construct()
{
$this->file = dirname(__FILE__).'/serialconfig.php';
echo '<br>xc'.$this->file.'xc<br>'; // testcode
$this->werte=array();
if(file_exists($this->file)) //<-muss doch bei 2-tem aufruf da sein, schau destruktor.
{
$s=file_get_contents($this->file);
$this->werte=unserialize(base64_decode($s));
}else echo __LINE__.")file $this->file nicht gefunden<br />";//<-das bekomme ich ständig
}

// gekürzt
}
Aber, warum das bei dir nicht funktioiert, ist mir auch noch nicht klar..

Original geschrieben von Slava vielleich habe ich einfach problem an betrieb System?
Aber ich will besser hoffen, dass ich ein logisches problem habe.
nur so als feedback, dein script funktioniert bei mir, die datei wird also angelegt.
hoffe, dass es dir erstmal weiterhilft - also am script liegt es nicht.
habe momentan aber auch keine idee, an welcher systemeinstellung es liegen könnte :(

Hi @highrise
Tatsächlich hat es bei 2-ter instanze hingehaut und der konstruktor hat keine meldung, dass die Datei nicht existiert.
nach dem ich kontrolliert habe, ob die datei im ordner ist (klingt jetzt wie eine fobie), habe ich sie auch entdeckt.

@combie
nach dem du mir clearstatcache() empfohlen hast, habe ich sofort verstanden, das das der richtiger weg ist, und habe diese funktion direkt im destrucktor und im construktor eingebaut.
Jetzt wundere ich mich aber , dass es nicht funktioniert hat.

ich habe sogar nach dem 10-em reload eine geraucht und auf dem Balkon geschimpft, jetzt sehe ich das Datei immer noch nicht da ist.

@3DMax
Danke.
ich werde jetzt einfach system noch mal hohfahren, vielleicht geht es wieder.

ich gehe noch eine rauchen
:( :confused:

getcwd() liefert die Antwort!
Der Destruktor läuft schon im Apache Umfeld.
Zumindest bei mir, mod_php

*edit*
clearstatcache war ein (zu)Schnellschuß von mir...

Original geschrieben von combie
Der Destruktor läuft schon im Apache Umfeld.
Zumindest bei mir, mod_php
läuft denn bei dir das script?
php läuft bei mir als cgi.

@slava - rauch' nicht soviel ;)

Tatsächlich ist aktuele pfad bei destructor im apache!!!!
wenn ich der absoluter pfad zur datei schreibe, dann funktioniert es sofort bei dem 2-tem reload.
Was für mich aber rätsel ist, Warum klappt es mit relativem Pfad, wenn ich einfach die 2-te Instanze erzeige?
Das ist nicht normal!

In Slavas Version nicht!
Nach dem Umbau im Konstruktor:
$this->file = dirname(__FILE__).'/serialconfig.php';
Auch bei mir...

getcwd() sagt bei mir:
Im Konstruktor H:\Programme\xampp\htdocs\fragmente
Im Destruktor H:\Programme\xampp\apache

Original geschrieben von combie
[B]In Slavas Version nicht!
das ist ja interessant.
und wenn du jetzt im php-script explizit (bzw. implizit) den destructor aufrufst?
$con=null sollte eigentlich ausreichen.

Tatsächlich ist aktuele pfad bei destructor im apache!!!!
wenn ich der absoluter pfad zur datei schreibe, dann funktioniert es sofort bei dem 2-tem reload.
Was für mich aber rätsel ist, Warum klappt es mit relativem Pfad, wenn ich einfach die 2-te Instanze erzeige?
Das ist nicht normal!

Das funktioniert, da das aktuelle Verzeichnis (getcwd) beim Zerstören des ersten Objektes noch im Verzeichnis des Skriptes ist, die Abarbeitung wurde schließlich noch nicht beendet! Hast du nur ein Objekt und du zerstörst dieses nicht explizit, wird es erst beim Aufräumen von PHP zerstört, das aktuelle Verzeichnis ist also im Apache-Verzeichnis.

Ok! ich kann es nachvollziehen, dass destruktor irgendwo in apache landet.
Jetzt verstehe ich andere sache nicht.
wenn ich nach dem
$con =new Configuration();
echo $con->wartung;

einfach
echo dirname(__FILE__);
mache, dann zeigt er mir wieder der pfad von /apache!
soll das heisen, dass nach dem der destructor gelaufen ist, wird der aktueler ordner grundsätzlich weiter in /apache laufen?

In jedem fall habe ich in docu nichts darüber gelesen.
Und man muss schon zugeben, dass so ein Verhalten nicht unbedingt freundlich ist.

Original geschrieben von 3DMax
das ist ja interessant.
und wenn du jetzt im php-script explizit (bzw. implizit) den destructor aufrufst?
$con=null sollte eigentlich ausreichen.

Dann ist es wie erwartet:
H:\Programme\xampp\htdocs\fragmente

Original geschrieben von combie
Dann ist es wie erwartet:
H:\Programme\xampp\htdocs\fragmente
danke, man lernt halt nie aus.

Und man muss schon zugeben, dass so ein Verhalten nicht unbedingt freundlich ist.
Evtl, ist das ein Fall für einen Bugreport..

nee!
also das ist für mich als ein BUG zu bezeichnen, dass wenn ich nicht der object zerstöre, bin ich auch ausserhalb von object immer noch im apache ordner.
$con =new Configuration();
echo $con->wartung;
//das darf nicht war sein.
echo dirname(__FILE__);//D:\Programme\xampp\apache ???

Original geschrieben von Slava

//das darf nicht war sein.
echo dirname(__FILE__);//D:\Programme\xampp\apache ???
kann ich nicht nachvollziehen, gibt mir den doc root aus

hm! jetzt geht es wieder, und ich bekomme mit dirname(__FILE__);
wieder ein aktueler ordnet.
kann jetzt aber nicht genau rekonstruiren was ich geändert habe.
die Frage warum es mit relativem pfad aber mit der 2-ter Instance geklappt hat kann ich immer noch nicht logisch beantworten.

nach dem, was hier so geschrieben wurde, ist mir das schon klar...

gewusst hätt ichs aber auch nicht...


solange das script noch läuft, ist der aktuelle Pfad gesetzt....

die datei wird also wie gewünscht in [current]/serialconfig.php geschrieben... deshalb kann sie auch von der zweiten instanz gefunden werden....

in dem moment, wo das script beendet, lautet (für welchen zeitraum genau kann ich nicht sagen) zumindest dann, wenn der destruktor aufgerufen wird, der aktuelle pfad ... blablubber/apache...

geschrieben wird also falsch, nämlich blablubber/apache/serialconfig.php

der destruktor selbst findet natürlich die datei wieder, denn währenddessen ändert sich ja der pfad nicht (beides mal falsch)...

das erklärt auch, warum die datei nicht im "richtigen" ordner aufgetaucht ist, denn sie wurde ja in einen völlig anderen geschrieben...

anyway... spannend wäre noch zu wissen, ob sich PHP als Apache-Modul und PHP als CGI/Fast-CGI unterschiedlich verhalten... (bei irgendwem hats ja funktioniert???)

kann das jemand herausfinden? hat vielleicht jemand beides am laufen?

greetz, high

Original geschrieben von highrise
anyway... spannend wäre noch zu wissen, ob sich PHP als Apache-Modul und PHP als CGI/Fast-CGI unterschiedlich verhalten... (bei irgendwem hats ja funktioniert???)
lesen ist nicht so deine stärke?

lesen ist nicht so deine stärke?

an und für sich schon, vielleicht nicht mehr um diese Zeit...

gehe ich richtig in der Annahme, dass sich deine Bemerkung auf die wage Annahme stützt, die Versionen verhielten sich unterschiedlich, weil sie sich in zwei völlig unterschiedlichen Installationen bei zwei völlig unterschiedlichen Personen vermutlich auch auf zwei völlig unterschiedlichen Servern komischerweise auch unterschiedlich verhalten?

die Analyse liefert dann aber eher ein suboptimales Ergebnis, weil ich jedenfalls keinerlei Aussage über die sonstige Konfiguration finden konnte...

Merkste was? Nur, weil es zufällig so hinhaut, muss es nicht zwingend notwendig an dem angesprochenen Umstand liegen...

However... über deinen zweiten belegbar falschen Schluss, Lesen sei nicht so meine Stärke (gut, dass wir darüber gesprochen haben) mag ich mich dann hier nicht auslassen, denn das war glaub ich gar nicht Thema...

Deshalb noch mal die Frage... hat jemand einen direkten Vergleich mit ansonsten nachvollziehbar identischer Konfiguration? Ich würds nämlich gerne wissen, und nicht nur vermuten...

greetz, high

---
no text :)

Ich kann lesen.....
(:D manchmal :D)
http://bugs.php.net/bug.php?id=34206

Original geschrieben von combie
Ich kann lesen.....
(:D manchmal :D)
http://bugs.php.net/bug.php?id=34206
wenn ich lesen könnte, würde ich das auch finden :)

Nicht jeder Fehler ist ein BUG, aber in meinem Fall habe ich wirklich ein Bug erwischt :-)
Ich danke allen, die mich von Paranoia (kurzfristig :) ) gerettet haben.

Das von dir angemeckerte Verhalten, scheint normal zu sein!! Taucht allerdings noch nicht in der Doku auf... :(
Danke für dein interessantes Problem!

Die Antwort war eigendlich für highrise bestimmt, welcher ja nicht wahrhaben will, dass sich das auf alle mod_php bezieht. Und dass das als CGI nicht auftreten kann.

Schade...

anstelle unsinniger Kommentare hätte der Link zum Bug ruhig ein paar Beiträge früher kommen können...

man hätte sich den ganzen Zores von wegen lesen oder nicht lesen sparen können...

Und ich Esel sagte vorgestern am Telefon zu Berni noch, dass dieses eines der zwei Foren sei, auf dem sich das Niveau noch auf einem höheren Level bewegt.... I admit, I was wrong...

da es einen direkten Zusammenhang zu geben scheint zwischen der Dauer der Mitgliedschaft in diesem Forum und dem Verlangen, Leute erst einmal runter zu putzen und zu kritisieren, anstatt produktiven Input zu leisten, habe ich etwas Sorge, ich könnte mit der zeit auch dahin verfallen...

In diesem Sinne...

I respectfully resign...

Macht's gut, Forum...

Vielleicht sieht man sich ja woanders mal wieder, zwischen Leuten, die noch mit etwas Anstand umzugehen wissen...

Streichen wir dir Liste der guten Foren in diesem Bereich wieder auf eins zusammen und hoffen, dass wenigstens dort noch für die User gepostet wird, und nicht fürs Ego

Ich wünsche allen anderen, dass sie für Ihre Probleme Hilfe finden und nicht nur Spott wegen Ihrer mangelnden Allwissenheit...


greetz, high

@highrise ich mag dich! :)
also bleib bitte mit uns.
wie du schon bemerkt hast, wurde diese Diskusion ziemlich spät angefangen und an diese Zeit sinkt Niveau bei allen drastisch (außer mir, da ich so wieso kein Niveau habe). Ich bin mir sicher, dass nimand dich wirklich verletzen wollte und danke dir persönlich für die geleistete Hilfe.

@highrise
1. Keinesfalls wollte ich dir irgendwie auf den Füssen rumtrampeln....
2. Ist der Bugreport in solchen Fällen immer die erste Anlaufstation, woher soll ich wissen, dass das bei dir anders ist?
3. usw...

na schön ihr Helden...

Entschuldigung akzeptiert...

versuche ich einfach mal, aus dem ganzen durcheinander kein Grundsatzproblem zu machen. Ich werde also weiterhin hier im Forum schreiben... Vielleicht hab ich auch etwas überreagiert, aber ich habe leider leider schon sehr oft gesehen, dass hier Leute häufig von oben herab behandelt werden.

Anyway... ich gestehe, ich habe in meinen 12 Jahren PHP-Entwicklung noch nicht einen Bug-Report gelesen... bisher war es auch nicht nötig, dank sehr umfangreicher Doku und selbstlosen Leuten, die ganze Webseiten zum Thema PHP veröffentlicht haben (Peter Kropff, Claudia Unkelbach und zahlreiche mehr) und auch wegen der Stolperstricke vieler User hier im Forum und meiner Nummer zwei auf der Liste.

Mag sein, dass ich etwas perplex war, dass nun bei diesem Problem tatsächlich ein Softwarefehler für Chaos gesort hat und meine üblichen Lösungsstrategien genau an der Stelle scheiterten...

Ich weiss nicht genau, ob nun meine Frage selbst sich als "dumme Frage" qualifiziert hat, oder der Nachschlag, den ich nochmal oben drauf gelegt habe... anyway... Schwamm drüber...

ich reagiere selbst ja auch vielleicht etwas schroff und bin geneigt bitterböse flames zu schreiben, wenn mir jemand auf die Füße tritt, auch wenn ich eigentlich ein ganz lieber bin...

so... dann hoffe ich mal, dass das Thema damit durch ist, und wir alle wieder am gleichen Strick ziehen können, wenn sich das nächste komische Phänomen auftut...

greetz, high

Auch wenn ich jetzt ein wenig pingelig werde:
Das mit der Pfadänderung im Destruktor, ist kein Bug im eigendlichen Sinn! Das "seltsamme" Verhalten ist nur nicht hinreichend genug dokumentiert.