Make WordPress Core

Opened 9 years ago

Closed 9 years ago

Last modified 9 years ago

#31811 closed defect (bug) (fixed)

Update error: not able to create directory

Reported by: afragen's profile afragen Owned by: dd32's profile dd32
Milestone: 4.2.2 Priority: normal
Severity: normal Version: 4.2
Component: Upgrade/Install Keywords:
Focuses: Cc:


At some point in the past few week my updates broke. I am using 4.2-beta3-31921 and I'm reasonable certain this did work in beta2.

This comes about when updating using my GitHub Updater plugin. The actual updating is from core the plugin just make core aware of the update.

Currently the error I'm getting is that I am unable to create a directory.

Updating works on 4.1.1

Attachments (2)

screenshot_01.png (53.5 KB) - added by afragen 9 years ago.
screenshot_02.png (45.7 KB) - added by afragen 9 years ago.

Download all attachments as: .zip

Change History (15)

9 years ago

9 years ago

#1 @dd32
9 years ago

  • Component changed from General to Upgrade/Install
  • Milestone changed from Awaiting Review to 4.2

Moving to 4.2 for investigation.

@afragen can you provide a direct link to a public plugin using the system for testing with? (latest version is fine)

#2 @afragen
9 years ago is what I use.

I'm doing some more testing and sometimes I get the error but the plugin does update.

#3 @dd32
9 years ago

As I somewhat suspected, it's because it tries to create a folder called 0, whereas previously it tried to create one called 0.tmp, as the basename of the URL it's downloading is 0 (ie. the file is 0.7.3).

That changed in #30945.

What I suspect is happening, is something is calling empty() on the directory name (0), but i'm not sure where yet.

#4 @afragen
9 years ago

Previously, creating a folder 0.tmp worked just fine. It must have been the addition of the extension. Thanks for letting me know I'm not going crazy.

FWIW, I seem to recall it always created a 0.tmp folder no matter what the actual download.

#5 @afragen
9 years ago

I didn't have the issue in #30945 because my plugin has a renaming function to fix this.

#6 @afragen
9 years ago

I think I found a solution, but I'm not set up to create a diff. Starts line 266 in /wp-admin/includes/class-wp-upgrader.php

		// We need a working directory - Strip off any .tmp or .zip suffixes
		// If empty after stripping create 'temp' name
		$package_stripped = basename( basename( $package, '.tmp' ), '.zip' );
		if ( empty( $package_stripped ) ) {
			$package_stripped = 'temp';
		$working_dir = $upgrade_folder . $package_stripped;

Last edited 9 years ago by afragen (previous) (diff)

#7 @dd32
9 years ago

  • Owner set to dd32
  • Resolution set to fixed
  • Status changed from new to closed

In 31936:

Add some logic into wp_tempnam to prevent it creating 'falsey' directory names that might get used elsewhere within WordPress.
Although this logic looks a little strange at this low level, it's the best location within the Upgrades code for it to happen.
Fixes #31811

#8 @afragen
9 years ago

Thanks @dd32. Looking forward to next nightly that has this fix.

#9 @dd32
9 years ago

In 32322:

When creating a temporary file treat the / directory properly, to prevent it ending up in an endless self-calling loop.
Props hnle, taka2. Fixes #32135. See #31811

#10 @dd32
9 years ago

In 32324:

When creating a temporary file treat the / directory properly, to prevent it ending up in an endless self-calling loop.
Props hnle, taka2. Fixes #32135. See #31811
Merges [32322] to the 4.2 branch.

#11 @samuelsidler
9 years ago

  • Milestone changed from 4.2 to 4.2.2

#12 @tellyworth
9 years ago

There's an obscure regression here. The old regex would strip the extension and add '.tmp' in one preg_replace. The new version strips the extension first, then concats '.tmp' separately, regardless of whether or not there was an extension passed in.

So the previous version, if given a filename with no extension, would produce a temp name with no extension. Now the result always has a '.tmp' extension, regardless of the input.

It's arguably correct behaviour, just posting here because we found a plugin that was tripped up by the change.

#13 @dd32
9 years ago

#32121 was marked as a duplicate.

Note: See TracTickets for help on using tickets.