From: [EMAIL PROTECTED] Operating system: Win 98 SP2 PHP version: 4.2.2 PHP Bug Type: Session related Bug description: session.save_path of php.ini not honored
My config is Win 98 SP2; Apache 1.3.23; PHP 4.2.2 with no php-related files in any windows or system folder (this is because I'd like to evaluate a new version in parallel - not having a second "identical" system) PHP is working fine in CGI mode (for example I use PHPmyAdmin 2.2rc4) and phpinfo() tells the correct path for the session files. With no change to the PHP inst or config but just by changing the PHP usage mode in Apaches httpd.conf from CGI to module mode (and closing and reopening Apache) this changes: in module mode session.save_path is ignored. I guess this comes from a dependency on the execution environment (namely the path of the executable), which is clearly changed by that action from php.exe to apache.exe. Without knowing all the details I guess the manual should clearly point out this difference between cgi and module mode. I bet it accounts for more uncertainty in using and spelling pathnames in php.ini which can be read out of the user comments that accompany the inst section of the manual. By the way: in module mode copying php.ini to the Apache.exe folder disables loading of the php extensions: here one seems to depend upon the location of php.ini which is looked for in the execution folder (of Apache.exe in ths case) in the first place and therefore ceases to be a good start for "./any folder". On the other hand: a parallel installation of PHP 4.3 ceases to work in CGI mode: I get "Server 500"- messages, whereas module mode allows for running some apps - for example PHPmyAdmin - but session.path_name is ignored here also. My conclusion (and request for feature) is to come up with the following strategy: locate a file "php-location.ini" in c:\windows. Sole content is the name of the root folder of the current PHP inst (The folder where php.exe, php4ts.dll and php.ini reside). All relative pathnames in php.ini should be based on this location. Alternatively a registry key could be used. Please take the corner and do not impose putting the dlls or php.ini into the system folder - this one is cluttered enough. Hope this is helpful. Sven -- Edit bug report at http://bugs.php.net/?id=20091&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=20091&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=20091&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=20091&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=20091&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=20091&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=20091&r=support Expected behavior: http://bugs.php.net/fix.php?id=20091&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=20091&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=20091&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=20091&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20091&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=20091&r=dst IIS Stability: http://bugs.php.net/fix.php?id=20091&r=isapi
