php.net |  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
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 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.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: stas at zend dot com
New email:
PHP Version: OS:

 

 [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

Add a Patch

Pull Requests

Add a Pull Request

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-2022 The PHP Group
All rights reserved.
Last updated: Mon Aug 08 00:05:45 2022 UTC