Upgrade from 5.4.0.3 to 5.4.1 zip error

Permalink 1 user found helpful
I am aware this issue pops up quite a bit after searching through the forum.

I am attempting to update to 5.4.1 and get the following message when attempting to update

The following errors occurred when attempting to process your request:
There was an error unpacking the file. Perhaps you have not uploaded a valid zip file, or you do not have zip installed.

I have gone through an checked zip and unzip are on the server (linux) I have also provided bin/bash access to the ftp account, and changed from apache.

The file is being downloaded to the tmp file but seems to fail on the
$zip->open($fh->getTemporaryDirectory() . '/' . $file) === TRUE

{/concret/libraries/archive.php}

I have tried changing the group, the owner, the permissions nothing seems to work?

both zip and unzip can be found in the usr/bin and I have defined the DIR_FILE_BIN's within site.php
define('DIR_FILES_BIN_UNZIP', '/usr/bin/unzip');
define('DIR_FILES_BIN_ZIP', '/usr/bin/zip');


I can manually update but it would be much better if I could actually update from within the browser.

I can update packages from the market place to.

Anyone have any ideas?

I have exhausted everything I can find on the server

TheRealSean
 
TheRealSean replied on at Permalink Reply
TheRealSean
I have noticed when the zip file is created it is given these permissions


-rw-r--r-- 1 apache apache 9767936 2010-10-07 11:40 1286448009.zip

or 644

Would this cause a problem?

Could it be that the server creates the zip but is then unable to open the file?

I am aware this should mean as the owner that apache should have permission to open the file but Im not fully up to speed with permissions and shell access.

*I have updated the site but have had to use the manual method
(unzip using shell access, move to update folder, run update script)
Mnkras replied on at Permalink Reply
Mnkras
you can always update manually, just copy the new /concrete directory over the old one and update

(make a sql backup first)
TheRealSean replied on at Permalink Reply
TheRealSean
Yes that's how I upgraded, all though used the version downloaded from the site and had to transfer using putty.

I keep getting this problem when updating major versions of concrete and was hoping someone would be able to point me towards a better solution, as asking our clients to download the software and then uploading them direct to the uploads directory is not always applicable
Mnkras replied on at Permalink Reply
Mnkras
its a server issue, probably a permission issue
TheRealSean replied on at Permalink Reply
TheRealSean
Mnkras, thank you for your time

I had thought that it was a permissions problem and had tried setting various owners, and permissions to combat this.

Setting the Files folder to 0777 recursively along with the updates folder.

Following through the archive.php,
The server is able to download the file, it then has trouble opening the zip file, thus throwing the exception.

But with 0777 and apache given full rights to the files folder this should have solved any permissions?

I am able to download and apply updates are these not done in a similar way?

Maybe since changing the settings I have changed the incorrect bits,

The folders as they stand now are
drwxrwxrwx 3 apache apache 4096 2010-10-07 12:20 updates
drwxrwxrwx 91 apache apache 4096 2010-10-07 14:23 files

Then within files, cache/incoming/tmp/trash are all set as being 0777

As far as I can tell everything appears as if it should work from here.

Changing the owner of the files folder to be my ftp user and then running through the same process above also resulted in the same failed update.

Am I applying these to the wrong directories/files?
Mnkras replied on at Permalink Reply
Mnkras
i am really not sure, does apache have write access to php's tmp directory
TheRealSean replied on at Permalink Reply
TheRealSean
yes apache has full access to the files folder, including all folders within it.

Apache does not have shell access though, Maybe this is the issue?.

I am against the idea of giving apache full shell access, as apache has access to every site on our server, I think that would then pose a potential security threat if someone where to be able to run command lines,

ie "rm -r"
I dont know if this is possible to run as apache but I would prefer to keep any shell access site local, maybe I need to look at altering the function to run as my site ftp user instead of using apache.
TheRealSean replied on at Permalink Reply
TheRealSean
I have tried allowing apache access to the bin/bash so that it can run unzip

But this still seems to fail.

Is there any out there who knows a way around this we run Plesk, so maybe someone has come up against and been able to solve this problem?

Current position is all folders within files are 0777, updates folder is 0777, Owner is Apache.

Zip file downloads but will not unzip(0777 permissions on the dir),

Zip/unzip has been defined in the site and is installed on the server.

I am able to use Putty to unzip the folder, (currently how I manually update each site). Then load update page, it works from here.
melat0nin replied on at Permalink Reply
melat0nin
I'm also having problems. I noticed that the update was only 1.8MB, which strikes me as slightly bizarre.. (I'm upgrading from 5.0.4.5).

Anyway, I tried manually unzipping the file inside the /files/tmp directory and I get this message (Gentoo):

unzip 1287770642.zip
Archive:  1287770642.zip
  End-of-central-directory signature not found.  Either this file is not
  a zipfile, or it constitutes one disk of a multi-part archive.  In the
  latter case the central directory and zipfile comment will be found on
  the last disk(s) of this archive.
unzip:  cannot find zipfile directory in one of 1287770642.zip or
        1287770642.zip.zip, and cannot find 1287770642.zip.ZIP, period.


Very strange!
nicolas replied on at Permalink Reply
nicolas
Your file is corrupted, correct size is around 9Mo
nicolas replied on at Permalink Best Answer Reply
nicolas
I've lost many hours on this problem and after checking everything, I find that it's a PHP 5.2 bug:

http://www.concrete5.org/developers/bugs/5-4-1/upgrade-failed-becau...

There is a patch in the report, maybe andrew will add it in a future release