Touch error during plugin upgrade

[mrmist]

Current trunk 12538 is giving me an error on my windows platform whenever I try to upgrade a plugin (any plugin)

PHP Warning: touch(): Utime failed: No such file or directory in E:\webpage\svn\trunk\wp-admin\includes\file.php on line 188

[dd32]

can you get the output of wp_tempnam() for me?

just through <?php echo wp_tempnam(); ?> at the top of a admin file and post up the result.

Is this Apache or IIS?

[mrmist]

Attempting to echo wp_tempnam also produces

PHP Warning: touch(): Utime failed: No such file or directory in E:\webpage\svn\trunk\wp-admin\includes\file.php on line 188

This is on IIS.

[dd32]

try var_dump(wp_tempnam()); instead of echo'ing it..

Looking at ​the function could you add a debug in there, Well, Replace it with this:

	function wp_tempnam($filename = '', $dir = ''){
var_dump("wp_tempnam($filename, $dir)");
	        if ( empty($dir) )
	                $dir = get_temp_dir();
	        $filename = basename($filename);
	        if ( empty($filename) )
	                $filename = time();
var_dump(compact('dir', 'filename'));
	        $filename = preg_replace('|\..*$|', '.tmp', $filename);
	        $filename = $dir . wp_unique_filename($dir, $filename);
var_dump(compact('filename'));
	        touch($filename);
	        return $filename;
	}

Take a look at the output, and check you have writable access to the directories mentioned.

Touch() is being used to create the file, so why its complaining it doesnt exist, seems to point to there being a issue accessing the path its chosen.

[mrmist]

Both attempts to var_dump and the modified proc result in the same message (the only difference being that the line number changes due to the changes in the proc.)

Has the behaviour here changed in 2.9? I've also noticed that theme files are no longer writable unless I add "authenticated user" write perms to the directory, which wasn't required in earlier revisions of WP. I suspect this is connected or similar.

[dd32]

Sorry, I was after the output from it.. Not the warnings.

The behaviour may have changed, which was why i was after the details.

The behaviour of that particular function has remained, but functions it depends on, specifically get_temp_dir() was changed, in that it also tries the upload_tmp_dir folder now.. But thats only after other methods fail, specifically, trying to write to the WP_CONTENT_DIR and trying sys_get_temp_dir()

Neither of those changes should've really affected you.

[mrmist]

OK I commented out the actual "touch" and this was the result of an attempted upgrade

string(77) "wp_tempnam(​http://downloads.wordpress.org/plugin/comment-timeout.2.1.1.zip, )" array(2) { dir?=> string(17) "C:\Windows\TEMP\/" filename?=> string(25) "comment-timeout.2.1.1.zip" } array(1) { filename?=> string(36) "C:\Windows\TEMP\/comment-timeout.tmp" }
Unpacking the update…

Incompatible archive PCLZIP_ERR_MISSING_FILE (-4) : Missing archive file 'C:\Windows\TEMP\/comment-timeout.tmp'

That extra slash looks odd to me.

[dd32]

That extra slash looks odd to me.

It does, But Windows has always handled it fine.

You can test this by changing $dir = .. line to this:

$dir = rtrim(get_temp_dir(), '\\/');

[mrmist]

It is as you say, that makes no difference. If I grant extra permissions to the iis user account to c:\windows\temp I can get a different message.

Unpacking the update…

Incompatible archive PCLZIP_ERR_READ_OPEN_FAIL (-2) : Unable to read archive 'C:\Windows\TEMP\/sem-dofollow.tmp'

But the files is not created, and (prior to this version of WP) this has always worked without issue.

[dd32]

Can you install a test of 2.8 and check what folder its creating the temporary files in?

It might be related to #6699, Whats your PHP.ini setting for 'upload_tmp_dir' ? I'm thinking that IIS has write access to that folder, but PHP doesnt, which wouldnt surprise me honestly. If thats the case, an extra is_writable() needs to be added

[mrmist]

Ok I've just installed a fresh 2.8 and it's giving the same behaviour, so I'm now thinking that this is some config change that has taken place on my computer without my knowing. Probably some MS patch or something has broken some permissions. It all used to work, but it doesn't seem as though it's WP that has broken.

Will do some more investigation and then come back and close this as invalid later.

[mrmist]

For info, the upload temp dir was blank which leads it to system default of c:\windows\temp

[dd32]

was the final result here that the filesystem permissions were set incorectly? (So invalid?)

[dd32]

closing as invalid for now. re-open if any information is available which points to a WordPRess bug.