On 26 March 2010 15:20, Bastien Helders <eldroskandar@xxxxxxxxx> wrote:
> I have checked the rights on the file for the first scenario and no user as
> locked it, I can see it, read it and write into it. I could even delete it
> if I wanted.
>
> For the second scenario, it doesn't even apply, as the exec('zip') that
> timeout try to create a new file (naturally in a folder where the web app
> user has all the necessary rights)
>
> In both case, it is no PHP timeout, as after the copy() in the first
> scenario, and the exec('zip') in the second scenario, the script continue to
> execute the other instructions, although the manipulation of the big files
> fails.
>
> But if it is not a PHP timeout, what is it?
>
> 2010/3/26 Richard Quadling <rquadling@xxxxxxxxxxxxxx>
>>
>> On 26 March 2010 12:21, Bastien Helders <eldroskandar@xxxxxxxxx> wrote:
>> > I already used error_reporting and set_time_limit and the use of
>> > ini_set('display_errors', 1); didn't display more exceptions.
>> >
>> > However the modification in the exec helped display STDERR I think.
>> >
>> > 1) In the first scenario we have the following:
>> >
>> > <STDERR>
>> > zip warning: ../../build/Patch-6-3-2_Q3P15.zip not found or empty
>> >
>> > zip error: Internal logic error (write error on zip file)
>> > </STDERR>
>> >
>> > The funny thing is, that now it is throwing status 5: "a severe error in
>> > the
>> > zipfile format was
>> > detected. Processing probably failed immediately." Why It throw a
>> > status 5
>> > instead of a status 14, I can't say.
>> >
>> > So that's using 'zip -gr', when I stop using the option g and then call
>> > exec('zip -r ...'), then I only get:
>> >
>> > <STDERR>
>> > zip error: Internal logic error (write error on zip file)
>> > </STDERR>
>> >
>> > 2) The error messages of the second scenario doesn't surprise me much:
>> >
>> > <STDERR>
>> > zip error: Unexpected end of zip file (build/Patch-6-3-2_Q3P15.zip)
>> > </STDERR>
>> >
>> > Which was already known, as the call of copy() on the old patch P14 crop
>> > it
>> > and thus prevent any operation to be done on it.
>>
>> So, the error is in the execution of the exec.
>>
>> Can you run the exec twice but to 2 different zip files.
>>
>> If the issue is that PHP is timing out, then the first error COULD be
>> due to the process being killed and if so, the second one won't start.
>>
>> But if the second one starts, then that pretty much rules out PHP
>> timeouts.
>>
>> I assume you've checked disk space and read access to the files in
>> question? i.e. they aren't locked by another user?
>>
>>
>> --
>> -----
>> Richard Quadling
>> "Standing on the shoulders of some very clever giants!"
>> EE : http://www.experts-exchange.com/M_248814.html
>> EE4Free : http://www.experts-exchange.com/becomeAnExpert.jsp
>> Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
>> ZOPA : http://uk.zopa.com/member/RQuadling
>
>
>
> --
> haXe - an open source web programming language
> http://haxe.org
>
I'm not sure. What is the exact command you are using?
I wonder if the zipArchive route would be easier.
According to the documentation, both Apache and IIS have similar
timeout values ...
"Your web server can have other timeout configurations that may also
interrupt PHP execution. Apache has a Timeout directive and IIS has a
CGI timeout function. Both default to 300 seconds. See your web server
documentation for specific details."
(http://docs.php.net/manual/en/info.configuration.php#ini.max-execution-time)
Can you run the command from the shell directly without any problems.
And run it repeatedly.
--
-----
Richard Quadling
"Standing on the shoulders of some very clever giants!"
EE : http://www.experts-exchange.com/M_248814.html
EE4Free : http://www.experts-exchange.com/becomeAnExpert.jsp
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
ZOPA : http://uk.zopa.com/member/RQuadling
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
