|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
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
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 Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
Block user comment
Status: Assign to:
Bug Type:
From: stas at zend dot com
New email:
PHP Version: OS:


 [2008-02-14 01:00 UTC] stas at zend dot com
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.


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2008-02-14 11:15 UTC]
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]
Hi Jani,

This patch should do it:

I only tested it in the console for now.

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

I will setup an apache + fcgi later this week to see if the hash works as expected :)
 [2008-02-18 11:29 UTC]
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]
And for the HOST sections this should propably be done always regardless of OS.
 [2008-02-18 11:37 UTC]
"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.


A possible solution would be to behave what the PHP stream functions do, comments?
 [2008-02-18 16:26 UTC]
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]
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]
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]
Jani, another question about the sections.

Is the following settings supposed to work?


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: Fri Mar 01 03:01:28 2024 UTC