php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #44114 [PATH=] in php.ini on windows does not account for case-insensitive FS
Submitted: 2008-02-14 01:00 UTC Modified: 2009-01-16 13:53 UTC
Votes:1
Avg. Score:3.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:1 (100.0%)
Same OS:1 (100.0%)
From: stas at zend dot com Assigned: pajoye (profile)
Status: No Feedback Package: CGI/CLI related
PHP Version: 5.3CVS-2008-02-14 (CVS) OS: * (with CiS FS)
Private report: No CVE-ID: None
View Developer Edit
 [2008-02-14 01:00 UTC] stas at zend dot com 
Description:
------------
When parsing [PATH=] section in php.ini, the value is taken as hash key as-is. Also, when calling a script its path is taken as-is from DOCROOT and file path. 
However, on Windows pathes are case-insensitive, meaning the path in script may differ in case from the path in config, but for Windows it would be the same path. It may be true also on other case-insensitive filesystems. 
The config parser should lowercase the names on Windows both when storing and when searching.

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2008-02-14 11:15 UTC] jani@php.net 
Yes, this stuff was never tested on Windows. :)
Mainly because I haven't got a dev env setup on my machine..
I'll look into this.
 [2008-02-17 13:45 UTC] pajoye@php.net 
Hi Jani,

This patch should do it:

http://blog.thepimp.net/patches/php53_ini_win32.patch.txt

I only tested it in the console for now.

Somehow the .user.ini are ignore when called like:

http://blog.thepimp.net/patches/callcgi.bat.txt

I will setup an apache + fcgi later this week to see if the hash works as expected :)
 [2008-02-18 11:29 UTC] jani@php.net 
Pierre, since  you have a patch and also win32 build env available, I'll  assign this to you. But aren't there other case-insensitive filesystems..? For example MacOSX has something like that..?
 [2008-02-18 11:36 UTC] jani@php.net 
And for the HOST sections this should propably be done always regardless of OS.
 [2008-02-18 11:37 UTC] pajoye@php.net 
"But aren't there other case-insensitive filesystems..? For example MacOSX has something like that..?"

Yes, a lot even. But it is going to be a pain if we have to manage all of them.

See:
http://en.wikipedia.org/wiki/Comparison_of_file_systems

A possible solution would be to behave what the PHP stream functions do, comments?
 [2008-02-18 16:26 UTC] pajoye@php.net 
A short discussion between Dmitry and me, it may be useful for other:

p: we use a hash to cache the settings, the keys come from the path
d: I think you should use virtual_file_ex()
p: that brings the issues about case insensitive filesystems
d: it should restore REAL case of the path

if it works we may use the same thing on all platforms and not only windows (file systems may not be platform specific).
 [2008-12-10 16:11 UTC] pajoye@php.net 
Not directly related to this bug, but could help to simplify the fix.

Do we need to support relative path in a section? [PATH=../../bar]

I do not see any sane usage for that (variables are more powerful/predictable and are supported and are expanded by the parser).
 [2008-12-10 16:27 UTC] stas@php.net 
I don't think relative pathes make any sense in PATH=. IMO, absolute only (and no UNC on Windows either :)
 [2008-12-10 19:47 UTC] pajoye@php.net 
Jani, another question about the sections.

Is the following settings supposed to work?

[PATH=/some/path]
include_path=".:/my/include/"


On linux, bsd and windows, it fails. The include path is not set when I am in this path (using cgi or cli).
 [2008-12-18 01:00 UTC] php-bugs at lists dot php dot net 
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Sat Dec 21 16:01:28 2024 UTC