Platform independence issues with the pclzip class

[westi]

This relates to #5586 but is worthy of it's own ticket.

From DD32 on wp-testers:

PCLZIP_ERR_BAD_FORMAT (-10) : Unable to find End of Central Dir Record signature

Unfortunately, Its something which i dont know how to work around, It appears to be > that the Zip class in use doesnt work 100% under certain web hosters setups..

I tracked it down to a small section of code, some Binary maths, Which makes no
sense to me, All i could tell, was that there was a chance that the integer was
reaching its maximum size or something (in other words) not much).

I'm using PHP 5.0.5 on the host affected by my bug.

From further investigation with DD32 it seems that some of the code in pclzip assumes that it is working with 32bit numbers.

This ticket is for us to work on resolving these issues.

[westi]

(In [7314]) Chase down some 64bit dragons. Ensure that we only ever create a 32bit number to compare to the 32bit magic number when searching a zip file for the end of the directory record. See #6236.

[DD32]

Commit has fixed the issues on my server setup :)

Cheers for your knowledge westi :P

[westi]

Replying to DD32:

Commit has fixed the issues on my server setup :)

Cool. I will send this upstream

[dougal]

I'm currently getting this (in r7331):

Fatal error: Call to a member function exists() on a non-object in [...my path...]/wp-admin/includes/class-wp-filesystem-ftpsockets.php on line 110

Declaring the $wp_filesystem variable as a global in the find_base_dir() method seems to fix that error. But:
1) The update seems to be slow as molasses on my system, and
2) I'm still getting zero-byte files during the unzip stage.

Are the built-in zip functions being used, when available? My system is PHP 5.2.1 with the ZIP extension installed.

And I still think this either needs to use AJAX, or we should put some flush() calls at various key points of the upgrade. There needs to be some sort of user feedback for slow updates, or users are going to be punching the "stop" button in their browsers, thinking that something has stalled.

[ryan]

(In [7334]) Fix var name. see #6236

[ryan]

(In [7335]) Fix var name. see #6236

[ryan]

Flushing can be added to show_message() in wp-admin/update.php

[DD32]

Are the built-in zip functions being used, when available? My system is PHP 5.2.1 with the ZIP extension installed.

Not yet, And probably not in this release, but i'd like it to be used if available, but not many people have it enabled.

And I still think this either needs to use AJAX, or we should put some flush() calls at various key points of the upgrade. There needs to be some sort of user feedback for slow updates, or users are going to be punching the "stop" button in their browsers, thinking that something has stalled.

If the webserver has an output buffer running, then theres nothing that can force it to flush out the page until its fully loaded, I've come accross it on Dreamhost, even adding some flushes didnt help.

However, On other servers without a forced output buffer, then the messages are shown as they happen.

Ajax wouldnt be possible in this situation, It'd simply make the output appear in one hit, rather than in small chunks. Someone suggested using HTTP Continues to load the page with one message, then in the same script execution, load the next "page" (but its the same page just with extra messages), But i've not a clue how to do that.

2) I'm still getting zero-byte files during the unzip stage.

Looking at the debug output you sent me, and its writing files correctly, Or at least the test file is, But aparantly not extracting properly for some reason.. i'll send back some small changes and see what that gives.

[westi]

Closing this as the original issue was fixed.

Please raise new tickets for any new issues.