Make WordPress Core

Opened 14 years ago

Closed 14 years ago

Last modified 14 years ago

#12230 closed defect (bug) (fixed)

Upgrade error - Incompatible Archive - ZipArchive

Reported by: wraithkenny's profile WraithKenny Owned by: dd32's profile dd32
Milestone: 3.0 Priority: normal
Severity: normal Version: 3.0
Component: Upgrade/Install Keywords:
Focuses: Cc:

Description

Upgrading to 3.0.alpha breaks upgrader, gets the message:

Downloading update from http://wordpress.org/nightly-builds/wordpress-latest.zip…

Unpacking the update…

Incompatible Archive.

Installation Failed

Started from a new install of 2.9.1 with a fresh database. Uploaded over FTP, ran install. Installed Beta Tester plugin. Put on Nightly branch, then upgraded. Immediately tried to upgrade and got error message. No error logs. Runs on RackSpaceCloud, if that matters.

possibly related to #10403 ?

Attachments (1)

12230.diff (1.8 KB) - added by dd32 14 years ago.

Download all attachments as: .zip

Change History (12)

#1 @WraithKenny
14 years ago

add_filter('unzip_file_use_ziparchive', create_function('', 'return false;')); 

This actually did allow the upgrade to work as suggested by Dion Hulse (dd32) on the mailing list:

"i *hope* it doesnt.. because that'll mean something weird is up with the PHP Zip extension"

#2 @dd32
14 years ago

So, The upgrade from 2.9 to 3.0 works, But the 3.0 to 3.0 upgrade fails?

I sent you a off-list message this morning, Basically asking for you to post your phpinfo(), see if i can work out what's causing it.

An option that we do have, is if the ZipArchive fails early(upon attempting to open the archive), we can attempt to use PclZip as we were in the past.

#3 @dd32
14 years ago

  • Summary changed from 3.0.alpha to Upgrade error - Incompatible Archive - ZipArchive

@dd32
14 years ago

#4 @dd32
14 years ago

attachment 12230.diff added

  • Causes it to fall through to PclZip if an error occurs during attempting to open the file.

WraithKenny: Feel like giving that a test on an affected server?

It shouldn't cause too much overhead, and will allow for any hosts where ZipArchive is available, but cannot handle the archive for whatever reason from failing..

#5 @dd32
14 years ago

This sounds like it could be caused from certain php limitations..

http://pecl.php.net/bugs/bug.php?id=8714

If it hits a certain number of open tmp file handles, it may choke.. (That limitation varies on the host). As of the latest PHP releases (5.3) it should be less of a issue due to the streams usage instead of file handles..

It sounds as if, every call to $z->statIndex($i) opens a temporary file handle, and it doesnt close it afterwards (Or has no way to close it).

Some workarounds suggested are to close the handle, and re-open it every x index's.

#6 @WraithKenny
14 years ago

dd32, I set you a reply, giving you access to that server. WP admin/FTP login is the same if you need.

#7 @WraithKenny
14 years ago

  • Cc WraithKenny added

#8 @WraithKenny
14 years ago

Patch (applied manually, i don't know how to do it otherwise) was successful on my server :-)

#9 @dd32
14 years ago

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

(In [13221]) Fallback to PclZip in the event that ZipArchive cannot handle a given archive properly. Close the Zip handle when we're done as well. Fixes #12230

#10 @nacin
14 years ago

  • Milestone changed from Unassigned to 3.0

Is echo "fall through to pcl"; leftover debug cruft?

#11 @nacin
14 years ago

(In [13223]) Remove debug cruft. Fixes #12230

Note: See TracTickets for help on using tickets.