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 imme­diately." 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

Reply via email to