Almost certainly this is because HFS+ is case-sensitive by default. Currently realpath "expands all symbolic links and resolves references to '/./', '/../' and extra '/' characters in the input path and returns the canonicalized absolute pathname".

Nowhere does that indicate anything about case sensitivity.

Well, I am still somewhat sympathetic to this though. The native OSX realpath() call does normalize the case. eg.

#include <stdio.h>
#include <stdlib.h>

int main(int argc, char **argv) {
        printf("%s %s\n",realpath("/Users",NULL),realpath("/users",NULL));
        return(0);
}

Outputs: /Users /Users

And we used to do so as well when we relied on the system-level realpath() call. However, after we optimized realpath() to allow us to do intra-path caching, we now use our own implementation.

Fixing this particular issue isn't that easy, and you are right, we don't promise to do path normalization in this function.

The doc says "returns the canonicalized absolute pathname"

"canonicalized" is what makes this a bug.

An other example that fails is require_once:

require_once 'TEST.PHP';
require_once 'test.php';

This does require the same file twice.

for the record HFS+ is optionally supports case sensitivity, but the current default is the case insensitive/preserve mode AFAIK.
I don't have a windows box at hand at the moment, but I'm fairly sure that realpath on windows does indeed correctly canonizes the path (http://www.php.net/realpath#example-2512 seems to be confirming this).

I think closing the issue with Not a bug is wrong, we should either keep it open until we can fix it, or mark as Won't fix, and document it.

Please note this is sill an issue. Either the documentation should be changed to warn the realpath function does NOT return canonical path (it currently says `realpath — Returns canonicalized absolute pathname`) or the function should be fixed.

I agree with tyrael: "I think closing the issue with Not a bug is wrong, we should either keep it open until we can fix it, or mark as Won't fix, and document it."

Side note, jpauli talks about the intra-path caching rasmus mentioned in this article: http://jpauli.github.io/2014/06/30/realpath-cache.html

Has this issue been tested with both case-sensitive AND case-insensitive HFS+ and are the results the same?

Or is it only an issue with case-insensitive HFS+?

on case-sensitive HFS there is no issue, as there is nothing to "normalize".
HFS+ by default is case-insensitive case-preserving, the same as NTFS on windows by default.
given how we support returning the preserved version of the filename on Windows/NTFS and the fact that the realpath libc function on mac seems to properly return the preserved version(used https://gist.github.com/Tyrael/68dc7d6e0b96c2c231e4 to test it) I think it would be expected to work that way from php also.

World Say News are sharing latest news about travel, tech, business, auto, home improvement, finance, entertainment etc. More info to visit: (https://worldsaynews.com)github.com