Updates still fail on Windows hosts

[billseyLCIS]

This seems to rear it's head with every update. file.php does not correctly handle Windows style separators, expecting instead of a '\' a '/'. The fix is simple, in file.php use:

if ( empty( $filename ) || '.' == $filename || DIRECTORY_SEPARATOR == $filename ) {

instead of:

if ( empty( $filename ) || '.' == $filename || '/' == $filename ) {

[ocean90]

Hello @billseyLCIS, welcome to Trac!

This is a duplicate of #33999 and something that we haven't been able to reproduce yet.

@billseyLCIS Would it be possible for you to provide the input to the function, and the value of $filename on each iteration of it? Any further info should be attached to #33999. Thank you!

[billseyLCIS]

I'm not sure how I would go about finding the input to the function or seeing what $filename is set to. Each time I've seen this it has been when a WP update has been released and I have selected the automatic update process. It fails with an out of memory error either at the beginning of the FTP transfers or at the end (I assume the former, since that would logically be when the paths are formulated). I think I still have an install image for one of the older versions, so I should be able to reproduce it, but I'll need some hand holding to get it to give me that info.

Though the suggested solution is the same, I don't believe the symptom is. In 33999 it seems to hang, in this one it errors out with out of memory errors. See ​https://wordpress.org/support/topic/cant-update-to-422-fatal-error-memory-size-exhausted?replies=18 and ​https://wordpress.org/support/topic/fatal-error-again-2?replies=6 for my previous issues with it.

[billseyLCIS]

OK, the next version has been released and I am again seeing the error.

Update WordPress

Downloading update from ​https://downloads.wordpress.org/release/wordpress-4.5.3-partial-2.zip…

Unpacking the update…

Verifying the unpacked files…

Preparing to install the latest version…

Enabling Maintenance mode…

Fatal error: Allowed memory size of 268435456 bytes exhausted (tried to allocate 65488 bytes) in C:\Web Files\localuser\CHCG\wp-admin\includes\file.php on line 175

I added a line just before the problem with:

echo "filename = ", $filename, "dir = ", $dir, "\n";

I'll attach the results here...

[billseyLCIS]

Results from test while in failure mode.

[billseyLCIS]

And I've redone that line a bit, to make the results come out better... To much C and not enough PHP in my life, I guess.

echo "filename = ", $filename, " dir = ", $dir, "<br>";

But that just locks my browser up with the data returned...

[billseyLCIS]

Locks up Firefox and Internet Explorer, Edge doesn't lock up, but also doesn't seem to have a method to copy the contents of a page. I'm guessing there's a nearly endless loop cycling on that "\" following the entry into Maintenance mode. The loop is what's running us out of memory.

When the echo is in place, it inserts a HTML EOL, so the memory is only allocated for the line of text. When the echo is removed, or doesn't have the EOL, memory is allocated while trying to build the string continuously until the out of memory error stops it. With the echo in place, it's never stopped so the displayed web page is constantly growing, which hangs the browsers...

[neogeneva]

It looks like this issue is caused by how dirname() returns slashes for root folders in Windows.

The following PHP demonstrates the issue:

<?php
echo dirname("/.maintenance")."<br/>".dirname("/wp-admin/includes/update-core.php");

The output is as follows:

\
/wp-admin/includes

So the result for the first dirname() flips the slash, which makes the assumption about slash direction in wp_tempnam() incorrect.

FYI: I'm using PHP 5.4.45 under Windows 10 1511

Edit: Just to clarify, this happens because wp_tempnam() attempts to strip the extension from files, and since the .maintenance file is only extension it ends up empty, and then calls itself recursively passing in the result of a call to dirname()

[ocean90]

@neogeneva Thanks for the hint, I could reproduce this behaviour. Let's continue the discussion on #33999.