Actually "C:PHP" is a valid path.
https://blogs.msdn.microsoft.com/jeremykuhne/2016/04/21/path-normalization/

Wow! thats suprising.

Thank you for clarifying this. I'll close this ticket.

Actually I'm not sure that's correct. In the blog you linked to, in the test script an environment variable is set;

// A hidden environment variable will be kept for each drive where a current directory is set
// (need to set via P/Invoke as .NET blocks this) 
SetEnvironmentVariableW(@"=C:", @"C:\Program Files");

I believe this is what allows 'C:Foo' to resolve to C:\Program Files\Foo. If you use dirname("C:PHP") it returns C:. however if you use dirname("C:PHP\Test") it will return C:PHP. Either way it does look like PHP is actually correct regarding is_dir but windows has some odd functionality regarding how this resolves.

Sorry, I meant to say, PHP is not correct with is_dir. Even if PHP is resolving this as a 'valid path' its not because windows cannot resolve it. Allowing this logic to proceed as 'working' means that further interactions with windows may cause further issues such as broken file paths such as I have witnessed.

Please re-open this ticket.

You can read "c:php" as ".\php on drive C:", this is documented scenario. Note, that "C:PHP\Test" is wrong, because '\t' is an escape sequence. Either DIRECTORY_SEPARATOR, manually doubled backslashes or single quotes have to be used.

Thanks.

Given that I have a copy of PHP runnable at E:\php56, from the command line:

C:\Windows>E:\php56 -r "var_dump(is_dir('C:Windows'));"
bool(false)

C:\Windows>E:
E:\>E:\php56 -r "var_dump(is_dir('C:Windows'));"
bool(false)

E:\>cd /d C:\
C:\>E:\php56 -r "var_dump(is_dir('C:Windows'));"
bool(true)

C:\>E:
E:\>E:\php56 -r "var_dump(is_dir('C:Windows'));"
bool(true)

Additionally,

E:\>E:\php56 -r "chdir('C:/Windows'); var_dump(is_dir('C:Windows'));"
bool(false)

E:\>E:\php56 -r "chdir('C:/'); var_dump(is_dir('C:Windows'));"
bool(true)

E:\>E:\php56 -r "chdir('C:/Windows'); chdir('E:/'); var_dump(is_dir('C:Windows'));"
bool(false)

E:\>E:\php56 -r "chdir('C:/'); chdir('E:/'); var_dump(is_dir('C:Windows'));"
bool(true)

All of those outputs are correct. I can't easily test is what happens from with IIS or Apache, but the only change in behavior that I would expect is that C: is always interpreted to be the root of the drive - "or the drive alone if none is set" clause from that link. But whatever happens, it is Windows making the decision. At least as far as this code is concerned...

@ab: "Documented scenario"? Where?

That's probably related to this: realpath isn't aware of drive-relative paths.
C:\Windows>E:
E:\>E:\php56 -r "var_dump(is_dir('C:System32')); var_dump(realpath('C:System32'));"
bool(true)
bool(false)

The bug is the inconsistency. Whether PHP enforces that C:foo is strictly equal to C:\foo or whether it obeys the rules of the operating system, all of the filesystem functions should work the same way.
https://github.com/php/php-src/blob/PHP-5.6.29/Zend/zend_virtual_cwd.c#L1260

@requinix https://msdn.microsoft.com/en-us/library/windows/desktop/aa365247%28v=vs.85%29.aspx?f=255&MSPPError=-2147217396#fully_qualified_vs._relative_paths

Otherwise yes, not all the path variants are currently supported across PHP implementation.

Thanks.

ab@php.net;

Regardless of the escape sequence it will not resolve to the correct path.

var_dump(dirname("C:PHP\Welcome")); #C:PHP
var_dump(dirname("C:PHP\\Welcome")); #C:PHP
var_dump(dirname("C:PHP\\Help\\Me")); #C:PHP\Help

If anything, the escape \ should resolve it to C:PHPelcome. 

I am running this directly using CLI so IIS and Apache has no influence on how this is resolved.

dirname, basename, etc. are string processing functions. They do not attempt to resolve the parameters to actual paths.

Thats my exact point but thats just a response to a previous comment. I think this ticket should stay closed however. With PHP7 maybe it will be resolved in the future. 

Thanks!

@steve dot baldwin at publisure dot com, the double backslash comment is related to is_dir, or actually any function that passes args to the Windows API. But with string parsing functions - dirname() of c:a\b is c:a, or of c:a\b\c is c:a\b, so that's correct. The path is not supposed to be resolved in these functions. Improvements to other rare path variant parsing could be done, yes, however i'm not sure it's a huge issue.

Thanks.