Hello,
I reported this bug one year ago (https://bugs.php.net/67220) and it is now
closed as "not a bug". I'd like this to be reconsidered.
The documentation of realpath() says:
realpath()expands all symbolic links and resolves references to '/./',
'/../' and extra '/' characters in the input path and returns the
canonicalized absolute pathname.
the last part of this description is IMO what qualifies this behavior on
MacOSX as a bug.
I'm asking for this now because I spend many hours on Syfony trying to find
an efficient workaround, and this is far from easy. Here is the fastest we
found (it's a mix of scandir()+getcwd()+caching):
https://github.com/symfony/symfony/pull/15443
If realpath were behaving on OSX the same as it does on Windows (and Linux),
I could remove 60 lines of wtf lines.
Do anyone else agree?
Regards,
Nicolas
On Tue, Aug 4, 2015 at 2:22 PM, Nicolas Grekas <nicolas.grekas+php@gmail.com
wrote:
Hello,
I reported this bug one year ago (https://bugs.php.net/67220) and it is
now
closed as "not a bug". I'd like this to be reconsidered.The documentation of
realpath()says:
realpath()expands all symbolic links and resolves references to '/./',
'/../' and extra '/' characters in the input path and returns the
canonicalized absolute pathname.the last part of this description is IMO what qualifies this behavior on
MacOSX as a bug.I'm asking for this now because I spend many hours on Syfony trying to find
an efficient workaround, and this is far from easy. Here is the fastest we
found (it's a mix ofscandir()+getcwd()+caching):
https://github.com/symfony/symfony/pull/15443If realpath were behaving on OSX the same as it does on Windows (and
Linux),
I could remove 60 lines of wtf lines.Do anyone else agree?
Regards,
Nicolas
I do and commented on the ticket last year.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
On Tue, Aug 4, 2015 at 2:22 PM, Nicolas Grekas <
nicolas.grekas+php@gmail.comwrote:
Hello,
I reported this bug one year ago (https://bugs.php.net/67220) and it is
now
closed as "not a bug". I'd like this to be reconsidered.The documentation of
realpath()says:
realpath()expands all symbolic links and resolves references to
'/./',
'/../' and extra '/' characters in the input path and returns the
canonicalized absolute pathname.the last part of this description is IMO what qualifies this behavior on
MacOSX as a bug.I'm asking for this now because I spend many hours on Syfony trying to
find
an efficient workaround, and this is far from easy. Here is the fastest
we
found (it's a mix ofscandir()+getcwd()+caching):
https://github.com/symfony/symfony/pull/15443If realpath were behaving on OSX the same as it does on Windows (and
Linux),
I could remove 60 lines of wtf lines.Do anyone else agree?
Regards,
NicolasI do and commented on the ticket last year.
I just re-opened the issue.
So the solution is weither we find a patch for the OSx case , or we patch
the documentation to reflect the actual behavior.
I confirm that patching realpath() can be tricky, as it expands to
thousands lines of code, but nothing is impossible.
For myself, I'm not OSx user, nor OSx fan, nor OSx developer, so I can't
myself do it, as I dont master that platform and don't care about related
bugs.
Julien.Pauli
Hi,
On Aug 4, 2015 7:23 PM, "Nicolas Grekas" nicolas.grekas+php@gmail.com
wrote:
Hello,
I reported this bug one year ago (https://bugs.php.net/67220) and it is
now
closed as "not a bug". I'd like this to be reconsidered.The documentation of
realpath()says:
realpath()expands all symbolic links and resolves references to '/./',
'/../' and extra '/' characters in the input path and returns the
canonicalized absolute pathname.the last part of this description is IMO what qualifies this behavior on
MacOSX as a bug.I'm asking for this now because I spend many hours on Syfony trying to
find
an efficient workaround, and this is far from easy. Here is the fastest we
found (it's a mix ofscandir()+getcwd()+caching):
https://github.com/symfony/symfony/pull/15443If realpath were behaving on OSX the same as it does on Windows (and
Linux),
I could remove 60 lines of wtf lines.Do anyone else agree?
I think it could be fixed but can be tricky.
For windows, there is no path normalization either btw. It would makes
realpath more expensive.
Also as far as I remember the case sensitivity on osx (for hfs) can be
enabled optionally, or?
Cheers,
Pierre
Regards,
Nicolas
Am 05.08.2015 um 17:06 schrieb Pierre Joye pierre.php@gmail.com:
Hi,
On Aug 4, 2015 7:23 PM, "Nicolas Grekas" nicolas.grekas+php@gmail.com
wrote:Hello,
I reported this bug one year ago (https://bugs.php.net/67220) and it is
now
closed as "not a bug". I'd like this to be reconsidered.The documentation of
realpath()says:
realpath()expands all symbolic links and resolves references to '/./',
'/../' and extra '/' characters in the input path and returns the
canonicalized absolute pathname.the last part of this description is IMO what qualifies this behavior on
MacOSX as a bug.I'm asking for this now because I spend many hours on Syfony trying to
find
an efficient workaround, and this is far from easy. Here is the fastest we
found (it's a mix ofscandir()+getcwd()+caching):
https://github.com/symfony/symfony/pull/15443If realpath were behaving on OSX the same as it does on Windows (and
Linux),
I could remove 60 lines of wtf lines.Do anyone else agree?
I think it could be fixed but can be tricky.
For windows, there is no path normalization either btw. It would makes
realpath more expensive.Also as far as I remember the case sensitivity on osx (for hfs) can be
enabled optionally, or?
Case sensitivity is not an issue of OS X but of the underlying Filesystem which is by default on HFS+ disabled. You can enable case sensitivity by reformating the partition using case-sensitive HFS+
Cheers
Andreas
--
Andreas Heigl
andreas@heigl.org
For windows, there is no path normalization either btw. It would makes
realpath more expensive.
I don't know what you mean by "no path normalization", but as far as the
case is concerned, there IS normalization:
var_dump(realpath(strtolower(FILE)));
var_dump(realpath(strtoupper(FILE)));
displays two times exactly the same string on Windows
On Aug 5, 2015 10:30 PM, "Nicolas Grekas" nicolas.grekas+php@gmail.com
wrote:
For windows, there is no path normalization either btw. It would makes
realpath more expensive.I don't know what you mean by "no path normalization", but as far as the
case is concerned, there IS normalization:
var_dump(realpath(strtolower(FILE)));
var_dump(realpath(strtoupper(FILE)));displays two times exactly the same string on Windows
I should had said there is not always normalization. I cannot remember
examples but similar functions (as per your bug report) do not normalize
path.
For windows, there is no path normalization either btw. It would makes
realpath more expensive.I don't know what you mean by "no path normalization", but as far as the
case is concerned, there IS normalization:
var_dump(realpath(strtolower(FILE)));
var_dump(realpath(strtoupper(FILE)));displays two times exactly the same string on Windows
FWIW, this case normalization happens in tsrm_realpath_r() by virtue of
FindFirstFile()[1] and later using the reported filename[2].
[1]
https://github.com/php/php-src/blob/php-7.0.0beta2/Zend/zend_virtual_cwd.c#L872
[2]
https://github.com/php/php-src/blob/php-7.0.0beta2/Zend/zend_virtual_cwd.c#L1143
--
Christoph M. Becker