Make wp_normalize_path() on Windows resolve drive letter for drive–relative paths

[Rarst]

Though rarely used, Windows allows to omit drive letter in file path to treat is as drive–relative.

This causes inconsistency where paths pointing to the same dir are not normalized to the same representation by wp_normalize_path():

<?php
var_dump( wp_normalize_path( 'C:\server\www\dev' ) );
// "C:/server/www/dev

var_dump( wp_normalize_path( '\server\www\dev' ) );
// /server/www/dev << same path, but mismatch after normalize

var_dump( wp_normalize_path( realpath( '\server\www\dev' ) ) );
// C:/server/www/dev << resolved drive letter before normalize

I think drive letter should be explicitly resolved as part of normalization for this case.

[Rarst]

One problem is that wp_normalize_path() doesn’t require path to be real, it normalizes path strings really. Introducing file_exists() check here feels somewhat unwanted.

Maybe we should introduce a new function, something like wp_normalize_real_path() that will both validate path as valid filesystem path and normalize it?

[costdev]

Rather than introduce a new function, or use file_exists() for all set ups, what about only running realpath() when the OS is windows, and the path begins with '/'?

Something like this:

<?php

// function wp_normalize_path...

// ...

/*
 * On Windows, if the path starts with '/' after normalizing,
 * try detecting the real path to apply the correct drive letter.
 */
if ( 'WIN' === strtoupper( substr( PHP_OS, 0, 3 ) ) && str_starts_with( $path, '/' ) ) {
    $realpath = realpath( $path );
    
    if ( is_string( $realpath ) ) {
        $path = $realpath;
    }
}

return $wrapper . $path;

This would mean having the correct result for existing paths, and local testing seems to show this working properly:

<?php

var_dump( wp_normalize_path( '\Users\costdev\test_normalize.php' ) );
// C:\Users\costdev\test_normalize.php

---

• As this would be new functionality, setting Version to 3.9 when wp_normalize_path() was introduced.
• Adding dev-feedback to gather thoughts.

[Rarst]

I now think making this check for a real file is too major of a backwards compatibility break. It's simply not what the function currently does and it's so generic, there is no way to tell what could that break in the wild.

By the way disk checks can be very expensive for performance. Hitting disk is much slower than memory and on Windows file exists checks are not as heavily cached by file system as on Linux, so they can cause massive slowdowns there, if called often. I would probably only consider introducing an implicit disk lookup if one is functionally unavoidable.