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. 2010/3/26 Richard Quadling <rquadl...@googlemail.com> > On 26 March 2010 08:51, Bastien Helders <eldroskan...@gmail.com> wrote: > > I've already specified the outputs, and it doesn't change if I put it in > a > > file. > > > > 1)In the first scenario, where all the data are compressed together, the > > only call of exec('zip') give this output: > > > > <OUTPUT> > > adding: bin/ (stored 0%) > > adding: bin/startHotFixInstaller.bat (deflated 41%) > > adding: bin/startHotFixInstaller.sh (deflated 49%) > > adding: software/ (stored 0%) > > adding: software/hotfixes/ (stored 0%) > > adding: software/hotfixes/hfFolder/ (stored 0%) > > [snip] > > adding: software/hotfixes/hfFolder/Patch-632Q3-033/Server/lib/julia.jar > > (deflated 4%) > > adding: software/hotfixes/hfFolder/Patch-632Q3-033/Server/software/ > > </OUTPUT> > > > > I snipped the output because it is a lot of the same, but, you'll notice > > that in the last line, the status of the file between parenthesis is > > missing, which leads me to think it has been interrupted. > > > > I've made a few research in between.Of note, the status with which he > > exited. Status 14 for the zip command means "error writing to a file". > But > > it isn't always at the same files. Also, I upped the value of > > "max_input_time" in php.ini from 60 to 600. Before the change the exec > > instructions took about 60 seconds before interrupting, after it takes > about > > 180-200 seconds and not 600 as expected. > > > > 2)In the second scenario, as said, I copy the previous patch (P14, which > > itself is a behemoth of a zip archive that was manually assembled) and > then > > add and delete only a few folders, each calling the function > exec('zip...'). > > Each time it ends with status 2, which means "unexpected end of zip > files". > > > > And there is no output to each of those commands. > > > > As for the single exec('zip..') in 1), the copy() of the previous patch > took > > about 60 seconds before the php.ini change and about 180-200 seconds > after. > > I take it that the copy() is interrupted thus explaining the "unexpected > end > > of zip files" (I can open the original patch P14 without any problem). > > > > I hope I made myself more clear on the details of my problem. > > > > Best Regards, > > Bastien > > > > > > 2010/3/25 Richard Quadling <rquadl...@googlemail.com> > >> > >> On 25 March 2010 13:31, Bastien Helders <eldroskan...@gmail.com> wrote: > >> > I'm really stumped, it seems that although the script is running under > >> > the > >> > time limit, if a single instruction such as exec("zip") in the first > >> > case, > >> > or copy() in the second case are timing out, because it takes too much > >> > time > >> > processing the big file. > >> > > >> > Is there any configuration in php.ini (or anywhere else) that I could > >> > change > >> > to permit copy() or exec("zip") to run through without being > >> > interrupted? > >> > > >> > Regards, > >> > Bastien > >> > > >> > >> What is the output of the exec when the command fails? > >> > >> Not the return value of exec() which is the last line, but the whole > >> thing, which is returned in the second parameter. > >> > >> If you can't see it due to pushing the file as part of the script, > >> then try something like ... > >> > >> > >> exec('zip ....', $Output); > >> file_put_contents('./ZipResults.txt', $Output); > >> > >> > >> > >> -- > >> ----- > >> 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 _think_ that the $Output will only hold STDOUT and not STDERR. > > Can you try this ... > > exec("zip .... 2>&1", $Output); > > > Also, > > error_reporting(-1); // Show ALL errors/warnings/notices. > ini_set('display_errors', 1); // Display them. > set_time_limit(0); // Allow run forever > > > -- > ----- > 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