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
2010/3/25 Bastien Helders <eldroskandar@xxxxxxxxx>
> Forgot to say, it is the second scenario that generate corrupted zip and
> text files with unexpected end of files.
>
> 2010/3/25 Bastien Helders <eldroskandar@xxxxxxxxx>
>
> So I tested two scenario:
>>
>> - First, I gather all the files selected for the patch and then compress
>> them together and here is what is displayed:
>>
>> [Begin display]
>> The command zip -gr ../../build/Patch-6-3-2_Q3P15.zip * returned a status
>> of 14 and the following 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%)
>> [snip]
>>
>> <br>
>>
>> <b>Warning</b>:
>> rename(build/Patch-6-3-2_Q3P15.zip,P:/Path_For_Deposit/Patch-6-3-2_Q3P15/Patch-6-3-2_Q3P15.zip)
>> [function.rename]: No such file or directory
>> [End display]
>>
>> I know that the rename didn't work, while the zip command aborted and
>> generated no zip file.
>> There is no problem with the README text file.
>>
>> - Second scenario, I take the previous patch, compare the list of folders
>> in the previous patch with list of selected folder, add the folders not in
>> the previous patch and eventually remove folders that weren't selected but
>> were in the previous patch.
>>
>> In this case, all the commands, may it be of the type
>> "zip -gr ../../build/Patch-6-3-2_Q3P15.zip
>> software/hotfixes/hfFolder/HF-632Q3-152/*" to add a folder or "zip -d
>> build/Patch-6-3-2_Q3P15.zip software/hotfixes/hfFolder/HF-632Q3-127\*" to
>> delete an unwanted folder returns all with status 2 and no output.
>>
>> 2010/3/24 Richard Quadling <rquadling@xxxxxxxxxxxxxx>
>>
>> On 24 March 2010 15:19, Bastien Helders <eldroskandar@xxxxxxxxx> wrote:
>>> > Hi Ashley,
>>> >
>>> > No, I set the time limit high enough
>>> (set_time_limit(2*HOUR+8*MINUTE);), and
>>> > the execution stops a long time before the time limit is reached.
>>> >
>>> > It might be relevent that the web application is hosted on a Windows
>>> > Machine.
>>> >
>>> > I asked myself, would setting the parameter "memory_limit" of the
>>> php.ini
>>> > file to a higher value help? Actually it is set to 128M. But I actually
>>> > don't have problems with creating a zip archive of about 250M (~80
>>> folders),
>>> > it actually occurs with 3 times bigger archives.
>>> >
>>> > Best Regards,
>>> > Bastien
>>> >
>>> > 2010/3/24 Ashley Sheridan <ash@xxxxxxxxxxxxxxxxxxxx>
>>> >
>>> >> On Wed, 2010-03-24 at 15:34 +0100, Bastien Helders wrote:
>>> >>
>>> >> Hi list,
>>> >>
>>> >> I've got this web app, which from a list of selected folders (with
>>> content)
>>> >> want to create a zip containing them as well as creating a text file
>>> with
>>> >> information about the chosen folders and how to use them.
>>> >>
>>> >> To create the zip file I use exec('zip -gr ' .$zipname.' * >>
>>> mylog.log');
>>> >> in the temporary folder where I gathered all the data (using a
>>> zipArchive
>>> >> object was more time consuming). I then create the text file using
>>> fopen,
>>> >> many fwrites and a fclose.
>>> >>
>>> >> My problem is the following, normally it creates the archive and text
>>> file
>>> >> without any problem, but as soon as the number of selected folder has
>>> an
>>> >> high value (let's say about 150 of them), I've got problems with the
>>> >> generated files: The zip archive doesn't contain all the folders and
>>> there
>>> >> is an unexpected end of file on both zip and text files.
>>> >>
>>> >> My guess is, as it takes too much time, the script goes on to the next
>>> >> operation and close the streams uncleanly. But I can't be sure about
>>> that,
>>> >> and I don't know where to investigate.
>>> >>
>>> >> Regards,
>>> >> Bastien
>>> >>
>>> >>
>>> >> Is the script maybe running past the max_execution_time before the zip
>>> >> files are completed?
>>> >>
>>> >>
>>> >> Thanks,
>>> >> Ash
>>> >> http://www.ashleysheridan.co.uk
>>> >>
>>> >>
>>> >>
>>> >
>>> >
>>> > --
>>> > haXe - an open source web programming language
>>> > http://haxe.org
>>> >
>>>
>>>
>>> Make sure you have ...
>>>
>>> error_reporting(-1); // show ALL errors/warnings/notices/etc.
>>>
>>> and ...
>>>
>>> exec($Command, $Output, $Status); // Capture the output.
>>> echo "The $Command returned a status of $Status and the following
>>> output:", PHP_EOL, implode(PHP_EOL, $Output), PHP_EOL;
>>>
>>> sort of thing.
>>>
>>> The error may be in the zip.
>>> --
>>> -----
>>> 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
>>
>
>
>
> --
> haXe - an open source web programming language
> http://haxe.org
>
--
haXe - an open source web programming language
http://haxe.org
