# realpath() on MacOSX doesn't normalize the case of characters - Thread: https://externals.io/message/87603 - Original archive: https://news-web.php.net/php.internals/87603 - Started by Nicolas Grekas on 2015-08-04T12:22:44+00:00 - Messages: 8 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · RFCs at https://externals.io/rfc.md · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #87603 — Nicolas Grekas — 2015-08-04T12:22:44+00:00 URL: https://externals.io/message/87603#87603 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 --- ## #87612 — Ferenc Kovacs — 2015-08-04T14:39:50+00:00 URL: https://externals.io/message/87603#87612 · In reply to: #87603 On Tue, Aug 4, 2015 at 2:22 PM, Nicolas Grekas 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: > > > […] > > 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 > I do and commented on the ticket last year. -- Ferenc Kovács @Tyr43l - http://tyrael.hu --- ## #87646 — Julien Pauli — 2015-08-05T14:28:34+00:00 URL: https://externals.io/message/87603#87646 · In reply to: #87612 > On Tue, Aug 4, 2015 at 2:22 PM, Nicolas Grekas < > nicolas.grekas+php@gmail.com > > […] > > > […] > '/./', > > […] > find > > […] > we > > […] > > I 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 --- ## #87648 — Pierre Joye — 2015-08-05T15:06:51+00:00 URL: https://externals.io/message/87603#87648 · In reply to: #87603 Hi, On Aug 4, 2015 7:23 PM, "Nicolas Grekas" 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: > > > […] > > 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? 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 --- ## #87649 — Andreas Heigl — 2015-08-05T15:23:39+00:00 URL: https://externals.io/message/87603#87649 · In reply to: #87648 > Am 05.08.2015 um 17:06 schrieb Pierre Joye : > > Hi, > > On Aug 4, 2015 7:23 PM, "Nicolas Grekas" > wrote: > > […] > now > > […] > find > > […] > Linux), > > […] > > 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 --- ## #87651 — Nicolas Grekas — 2015-08-05T15:30:28+00:00 URL: https://externals.io/message/87603#87651 · In reply to: #87648 > > 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 --- ## #87652 — Pierre Joye — 2015-08-05T17:03:01+00:00 URL: https://externals.io/message/87603#87652 · In reply to: #87651 On Aug 5, 2015 10:30 PM, "Nicolas Grekas" wrote: > > […] 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. --- ## #87654 — Christoph Becker — 2015-08-05T18:57:02+00:00 URL: https://externals.io/message/87603#87654 · In reply to: #87651 > > […] > > 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] [2] -- Christoph M. Becker