Zip and text files generated are corrupted
Zip and text files generated are corrupted
am 24.03.2010 15:34:33 von Bastien Helders
--0016e65c88e8308a7804828cd495
Content-Type: text/plain; charset=ISO-8859-1
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
--0016e65c88e8308a7804828cd495--
Re: Zip and text files generated are corrupted
am 24.03.2010 15:57:27 von Ashley Sheridan
--=-yTlgXiLscnF9xqYSLjcP
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
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
--=-yTlgXiLscnF9xqYSLjcP--
Re: Zip and text files generated are corrupted
am 24.03.2010 16:19:06 von Bastien Helders
--0016e6567e6c7db9bf04828d73e5
Content-Type: text/plain; charset=ISO-8859-1
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
> 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
--0016e6567e6c7db9bf04828d73e5--
Re: Zip and text files generated are corrupted
am 24.03.2010 16:24:56 von Richard Quadling
On 24 March 2010 15:19, Bastien Helders 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 folder=
s),
> it actually occurs with 3 times bigger archives.
>
> Best Regards,
> Bastien
>
> 2010/3/24 Ashley Sheridan
>
>> Â 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 conte=
nt)
>> want to create a zip containing them as well as creating a text file wit=
h
>> 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 zipArchiv=
e
>> 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 fi=
le
>> 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 the=
re
>> 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 tha=
t,
>> 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.
--=20
-----
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=3DZEND002498&r=3D213474=
731
ZOPA : http://uk.zopa.com/member/RQuadling
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
RE: Zip and text files generated are corrupted
am 24.03.2010 16:36:24 von Mike Roberts
Remove
Sincerely,
Michael Roberts
Executive Recruiter
Corporate Staffing Services
150 Monument Road, Suite 510
Bala Cynwyd, PA 19004
P 610-771-1084
F 610-771-0390
E mroberts@jobscss.com
Check out my recent feature article in Professional Surveyor 12/09
edition.=20
http://www.profsurv.com/magazine/article.aspx?i=3D70379
-----Original Message-----
From: Bastien Helders [mailto:eldroskandar@gmail.com]=20
Sent: Wednesday, March 24, 2010 11:19 AM
To: ash@ashleysheridan.co.uk
Cc: php-general@lists.php.net
Subject: Re: [PHP]Zip and text files generated are corrupted
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
> 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
>
>
>
--=20
haXe - an open source web programming language
http://haxe.org
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
RE: Zip and text files generated are corrupted
am 24.03.2010 16:36:33 von Mike Roberts
cmVtb3ZlDQoNCg0KDQoNCg0KIFNpbmNlcmVseSwNCg0KIE1pY2hhZWwgUm9i ZXJ0cw0KRXhlY3V0
aXZlIFJlY3J1aXRlcg0KIENvcnBvcmF0ZSBTdGFmZmluZyBTZXJ2aWNlcw0K IDE1MCBNb251bWVu
dCBSb2FkLCBTdWl0ZSA1MTANCiBCYWxhIEN5bnd5ZCwgUEEgMTkwMDQNCiBQ IDYxMC03NzEtMTA4
NA0KIEYgNjEwLTc3MS0wMzkwDQogRSBtcm9iZXJ0c0Bqb2JzY3NzLmNvbQ0K Q2hlY2sgb3V0IG15
IHJlY2VudCBmZWF0dXJlIGFydGljbGUgaW4gUHJvZmVzc2lvbmFsIFN1cnZl eW9yIDEyLzA5IGVk
aXRpb24uIA0KaHR0cDovL3d3dy5wcm9mc3Vydi5jb20vbWFnYXppbmUvYXJ0 aWNsZS5hc3B4P2k9
NzAzNzkNCg0KDQoNCg0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCkZyb206IFJp
Y2hhcmQgUXVhZGxpbmcgW21haWx0bzpycXVhZGxpbmdAZ29vZ2xlbWFpbC5j b21dIA0KU2VudDog
V2VkbmVzZGF5LCBNYXJjaCAyNCwgMjAxMCAxMToyNSBBTQ0KVG86IEJhc3Rp ZW4gSGVsZGVycw0K
Q2M6IGFzaEBhc2hsZXlzaGVyaWRhbi5jby51azsgcGhwLWdlbmVyYWxAbGlz dHMucGhwLm5ldA0K
U3ViamVjdDogUmU6IFtQSFBdWmlwIGFuZCB0ZXh0IGZpbGVzIGdlbmVyYXRl ZCBhcmUgY29ycnVw
dGVkDQoNCk9uIDI0IE1hcmNoIDIwMTAgMTU6MTksIEJhc3RpZW4gSGVsZGVy cyA8ZWxkcm9za2Fu
ZGFyQGdtYWlsLmNvbT4gd3JvdGU6DQo+IEhpIEFzaGxleSwNCj4NCj4gTm8s IEkgc2V0IHRoZSB0
aW1lIGxpbWl0IGhpZ2ggZW5vdWdoIChzZXRfdGltZV9saW1pdCgyKkhPVVIr OCpNSU5VVEUpOyks
IGFuZA0KPiB0aGUgZXhlY3V0aW9uIHN0b3BzIGEgbG9uZyB0aW1lIGJlZm9y ZSB0aGUgdGltZSBs
aW1pdCBpcyByZWFjaGVkLg0KPg0KPiBJdCBtaWdodCBiZSByZWxldmVudCB0 aGF0IHRoZSB3ZWIg
YXBwbGljYXRpb24gaXMgaG9zdGVkIG9uIGEgV2luZG93cw0KPiBNYWNoaW5l Lg0KPg0KPiBJIGFz
a2VkIG15c2VsZiwgd291bGQgc2V0dGluZyB0aGUgcGFyYW1ldGVyICJtZW1v cnlfbGltaXQiIG9m
IHRoZSBwaHAuaW5pDQo+IGZpbGUgdG8gYSBoaWdoZXIgdmFsdWUgaGVscD8g QWN0dWFsbHkgaXQg
aXMgc2V0IHRvIDEyOE0uIEJ1dCBJIGFjdHVhbGx5DQo+IGRvbid0IGhhdmUg cHJvYmxlbXMgd2l0
aCBjcmVhdGluZyBhIHppcCBhcmNoaXZlIG9mIGFib3V0IDI1ME0gKH44MCBm b2xkZXJzKSwNCj4g
aXQgYWN0dWFsbHkgb2NjdXJzIHdpdGggMyB0aW1lcyBiaWdnZXIgYXJjaGl2 ZXMuDQo+DQo+IEJl
c3QgUmVnYXJkcywNCj4gQmFzdGllbg0KPg0KPiAyMDEwLzMvMjQgQXNobGV5 IFNoZXJpZGFuIDxh
c2hAYXNobGV5c2hlcmlkYW4uY28udWs+DQo+DQo+PiDCoE9uIFdlZCwgMjAx MC0wMy0yNCBhdCAx
NTozNCArMDEwMCwgQmFzdGllbiBIZWxkZXJzIHdyb3RlOg0KPj4NCj4+IEhp IGxpc3QsDQo+Pg0K
Pj4gSSd2ZSBnb3QgdGhpcyB3ZWIgYXBwLCB3aGljaCBmcm9tIGEgbGlzdCBv ZiBzZWxlY3RlZCBm
b2xkZXJzICh3aXRoIGNvbnRlbnQpDQo+PiB3YW50IHRvIGNyZWF0ZSBhIHpp cCBjb250YWluaW5n
IHRoZW0gYXMgd2VsbCBhcyBjcmVhdGluZyBhIHRleHQgZmlsZSB3aXRoDQo+ PiBpbmZvcm1hdGlv
biBhYm91dCB0aGUgY2hvc2VuIGZvbGRlcnMgYW5kIGhvdyB0byB1c2UgdGhl bS4NCj4+DQo+PiBU
byBjcmVhdGUgdGhlIHppcCBmaWxlIEkgdXNlIGV4ZWMoJ3ppcCAtZ3IgJyAu JHppcG5hbWUuJyAq
ID4+IG15bG9nLmxvZycpOw0KPj4gaW4gdGhlIHRlbXBvcmFyeSBmb2xkZXIg d2hlcmUgSSBnYXRo
ZXJlZCBhbGwgdGhlIGRhdGEgKHVzaW5nIGEgemlwQXJjaGl2ZQ0KPj4gb2Jq ZWN0IHdhcyBtb3Jl
IHRpbWUgY29uc3VtaW5nKS4gSSB0aGVuIGNyZWF0ZSB0aGUgdGV4dCBmaWxl IHVzaW5nIGZvcGVu
LA0KPj4gbWFueSBmd3JpdGVzIGFuZCBhIGZjbG9zZS4NCj4+DQo+PiBNeSBw cm9ibGVtIGlzIHRo
ZSBmb2xsb3dpbmcsIG5vcm1hbGx5IGl0IGNyZWF0ZXMgdGhlIGFyY2hpdmUg YW5kIHRleHQgZmls
ZQ0KPj4gd2l0aG91dCBhbnkgcHJvYmxlbSwgYnV0IGFzIHNvb24gYXMgdGhl IG51bWJlciBvZiBz
ZWxlY3RlZCBmb2xkZXIgaGFzIGFuDQo+PiBoaWdoIHZhbHVlIChsZXQncyBz YXkgYWJvdXQgMTUw
IG9mIHRoZW0pLCBJJ3ZlIGdvdCBwcm9ibGVtcyB3aXRoIHRoZQ0KPj4gZ2Vu ZXJhdGVkIGZpbGVz
OiBUaGUgemlwIGFyY2hpdmUgZG9lc24ndCBjb250YWluIGFsbCB0aGUgZm9s ZGVycyBhbmQgdGhl
cmUNCj4+IGlzIGFuIHVuZXhwZWN0ZWQgZW5kIG9mIGZpbGUgb24gYm90aCB6 aXAgYW5kIHRleHQg
ZmlsZXMuDQo+Pg0KPj4gTXkgZ3Vlc3MgaXMsIGFzIGl0IHRha2VzIHRvbyBt dWNoIHRpbWUsIHRo
ZSBzY3JpcHQgZ29lcyBvbiB0byB0aGUgbmV4dA0KPj4gb3BlcmF0aW9uIGFu ZCBjbG9zZSB0aGUg
c3RyZWFtcyB1bmNsZWFubHkuIEJ1dCBJIGNhbid0IGJlIHN1cmUgYWJvdXQg dGhhdCwNCj4+IGFu
ZCBJIGRvbid0IGtub3cgd2hlcmUgdG8gaW52ZXN0aWdhdGUuDQo+Pg0KPj4g UmVnYXJkcywNCj4+
IEJhc3RpZW4NCj4+DQo+Pg0KPj4gSXMgdGhlIHNjcmlwdCBtYXliZSBydW5u aW5nIHBhc3QgdGhl
IG1heF9leGVjdXRpb25fdGltZSBiZWZvcmUgdGhlIHppcA0KPj4gZmlsZXMg YXJlIGNvbXBsZXRl
ZD8NCj4+DQo+Pg0KPj4gwqAgVGhhbmtzLA0KPj4gQXNoDQo+PiBodHRwOi8v d3d3LmFzaGxleXNo
ZXJpZGFuLmNvLnVrDQo+Pg0KPj4NCj4+DQo+DQo+DQo+IC0tDQo+IGhhWGUg LSBhbiBvcGVuIHNv
dXJjZSB3ZWIgcHJvZ3JhbW1pbmcgbGFuZ3VhZ2UNCj4gaHR0cDovL2hheGUu b3JnDQo+DQoNCg0K
TWFrZSBzdXJlIHlvdSBoYXZlIC4uLg0KDQplcnJvcl9yZXBvcnRpbmcoLTEp OyAvLyBzaG93IEFM
TCBlcnJvcnMvd2FybmluZ3Mvbm90aWNlcy9ldGMuDQoNCmFuZCAuLi4NCg0K ZXhlYygkQ29tbWFu
ZCwgJE91dHB1dCwgJFN0YXR1cyk7IC8vIENhcHR1cmUgdGhlIG91dHB1dC4N CmVjaG8gIlRoZSAk
Q29tbWFuZCByZXR1cm5lZCBhIHN0YXR1cyBvZiAkU3RhdHVzIGFuZCB0aGUg Zm9sbG93aW5nDQpv
dXRwdXQ6IiwgUEhQX0VPTCwgaW1wbG9kZShQSFBfRU9MLCAkT3V0cHV0KSwg UEhQX0VPTDsNCg0K
c29ydCBvZiB0aGluZy4NCg0KVGhlIGVycm9yIG1heSBiZSBpbiB0aGUgemlw Lg0KLS0gDQotLS0t
LQ0KUmljaGFyZCBRdWFkbGluZw0KIlN0YW5kaW5nIG9uIHRoZSBzaG91bGRl cnMgb2Ygc29tZSB2
ZXJ5IGNsZXZlciBnaWFudHMhIg0KRUUgOiBodHRwOi8vd3d3LmV4cGVydHMt ZXhjaGFuZ2UuY29t
L01fMjQ4ODE0Lmh0bWwNCkVFNEZyZWUgOiBodHRwOi8vd3d3LmV4cGVydHMt ZXhjaGFuZ2UuY29t
L2JlY29tZUFuRXhwZXJ0LmpzcA0KWmVuZCBDZXJ0aWZpZWQgRW5naW5lZXIg OiBodHRwOi8vemVu
ZC5jb20vemNlLnBocD9jPVpFTkQwMDI0OTgmcj0yMTM0NzQ3MzENClpPUEEg OiBodHRwOi8vdWsu
em9wYS5jb20vbWVtYmVyL1JRdWFkbGluZw0KDQotLSANClBIUCBHZW5lcmFs IE1haWxpbmcgTGlz
dCAoaHR0cDovL3d3dy5waHAubmV0LykNClRvIHVuc3Vic2NyaWJlLCB2aXNp dDogaHR0cDovL3d3
dy5waHAubmV0L3Vuc3ViLnBocA0KDQo=
Re: Zip and text files generated are corrupted
am 25.03.2010 10:40:00 von Bastien Helders
--001636416b799a92da04829cd415
Content-Type: text/plain; charset=ISO-8859-1
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]
Warning:
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
> On 24 March 2010 15:19, Bastien Helders 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
> >
> >> 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
--001636416b799a92da04829cd415--
Re: Zip and text files generated are corrupted
am 25.03.2010 10:42:03 von Bastien Helders
--00163642688ff90fb604829cdb0c
Content-Type: text/plain; charset=ISO-8859-1
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
> 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]
>
>
>
> Warning:
> 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
>
> On 24 March 2010 15:19, Bastien Helders 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
>> >
>> >> 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
--00163642688ff90fb604829cdb0c--
Re: Zip and text files generated are corrupted
am 25.03.2010 14:31:34 von Bastien Helders
--0016e64c05cec616370482a0109b
Content-Type: text/plain; charset=ISO-8859-1
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
> 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
>
> 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]
>>
>>
>>
>> Warning:
>> 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
>>
>> On 24 March 2010 15:19, Bastien Helders 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
>>> >
>>> >> 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
--0016e64c05cec616370482a0109b--
RE: Zip and text files generated are corrupted
am 25.03.2010 14:56:24 von Mike Roberts
remove
Sincerely,
Michael Roberts
Executive Recruiter
Corporate Staffing Services
150 Monument Road, Suite 510
Bala Cynwyd, PA 19004
P 610-771-1084
F 610-771-0390
E mroberts@jobscss.com
Check out my recent feature article in Professional Surveyor 12/09
edition.=20
http://www.profsurv.com/magazine/article.aspx?i=3D70379
-----Original Message-----
From: Bastien Helders [mailto:eldroskandar@gmail.com]=20
Sent: Thursday, March 25, 2010 9:32 AM
To: RQuadling@googlemail.com
Cc: ash@ashleysheridan.co.uk; php-general@lists.php.net
Subject: Re: [PHP]Zip and text files generated are corrupted
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
> 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
>
> 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]
>>
>>
>>
>> Warning:
>>
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
>>
>> On 24 March 2010 15:19, Bastien Helders
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
>>> >
>>> >> 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=3DZEND002498&r=3D213474731
>>> 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
>
--=20
haXe - an open source web programming language
http://haxe.org
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: Zip and text files generated are corrupted
am 25.03.2010 17:26:21 von Richard Quadling
On 25 March 2010 13:31, Bastien Helders 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
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: Zip and text files generated are corrupted
am 26.03.2010 09:51:50 von Bastien Helders
--00163642651b3caf0b0482b046e1
Content-Type: text/plain; charset=ISO-8859-1
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:
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
> On 25 March 2010 13:31, Bastien Helders 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
--00163642651b3caf0b0482b046e1--
Re: Zip and text files generated are corrupted
am 26.03.2010 12:19:37 von Richard Quadling
On 26 March 2010 08:51, Bastien Helders 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:
>
>
>
> 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
>>
>> On 25 March 2010 13:31, Bastien Helders 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
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: Zip and text files generated are corrupted
am 26.03.2010 13:21:42 von Bastien Helders
--002354187ba4c642f70482b33418
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
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:
zip warning: ../../build/Patch-6-3-2_Q3P15.zip not found or empty
zip error: Internal logic error (write error on zip file)
The funny thing is, that now it is throwing status 5: "a severe error in th=
e
zipfile format was
detected. Processing probably failed imme=ADdiately." 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:
zip error: Internal logic error (write error on zip file)
2) The error messages of the second scenario doesn't surprise me much:
zip error: Unexpected end of zip file (build/Patch-6-3-2_Q3P15.zip)
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
> On 26 March 2010 08:51, Bastien Helders wrote:
> > I've already specified the outputs, and it doesn't change if I put it i=
n
> a
> > file.
> >
> > 1)In the first scenario, where all the data are compressed together, th=
e
> > only call of exec('zip') give this output:
> >
> >
> >
> > I snipped the output because it is a lot of the same, but, you'll notic=
e
> > 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, whic=
h
> > 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 "unexpecte=
d
> 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
> >>
> >> On 25 March 2010 13:31, Bastien Helders wrote=
:
> >> > I'm really stumped, it seems that although the script is running und=
er
> >> > 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 mu=
ch
> >> > time
> >> > processing the big file.
> >> >
> >> > Is there any configuration in php.ini (or anywhere else) that I coul=
d
> >> > 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=3DZEND002498&r=3D213474731
> >> 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=3DZEND002498&r=3D2134=
74731
> ZOPA : http://uk.zopa.com/member/RQuadling
>
--=20
haXe - an open source web programming language
http://haxe.org
--002354187ba4c642f70482b33418--
Re: Zip and text files generated are corrupted
am 26.03.2010 13:27:51 von Richard Quadling
On 26 March 2010 12:21, Bastien Helders 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:
>
>
> zip warning: ../../build/Patch-6-3-2_Q3P15.zip not found or empty
>
> zip error: Internal logic error (write error on zip file)
>
>
> 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 s=
tatus 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:
>
>
> zip error: Internal logic error (write error on zip file)
>
>
> 2) The error messages of the second scenario doesn't surprise me much:
>
>
> zip error: Unexpected end of zip file (build/Patch-6-3-2_Q3P15.zip)
>
>
> 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?
--=20
-----
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=3DZEND002498&r=3D213474=
731
ZOPA : http://uk.zopa.com/member/RQuadling
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: Zip and text files generated are corrupted
am 26.03.2010 16:20:06 von Bastien Helders
--0016e65aed86c56cde0482b5b2f3
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
I have checked the rights on the file for the first scenario and no user a=
s
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 t=
o
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
> On 26 March 2010 12:21, Bastien Helders 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:
> >
> >
> > zip warning: ../../build/Patch-6-3-2_Q3P15.zip not found or empty
> >
> > zip error: Internal logic error (write error on zip file)
> >
> >
> > The funny thing is, that now it is throwing status 5: "a severe error i=
n
> the
> > zipfile format was
> > detected. Processing probably failed imme=ADdiately." Why It throw a st=
atus
> 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:
> >
> >
> > zip error: Internal logic error (write error on zip file)
> >
> >
> > 2) The error messages of the second scenario doesn't surprise me much:
> >
> >
> > zip error: Unexpected end of zip file (build/Patch-6-3-2_Q3P15.zip)
> >
> >
> > Which was already known, as the call of copy() on the old patch P14 cro=
p
> 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 timeout=
s.
>
> 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=3DZEND002498&r=3D2134=
74731
> ZOPA : http://uk.zopa.com/member/RQuadling
>
--=20
haXe - an open source web programming language
http://haxe.org
--0016e65aed86c56cde0482b5b2f3--
Re: Zip and text files generated are corrupted
am 26.03.2010 16:54:20 von Richard Quadling
On 26 March 2010 15:20, Bastien Helders 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 i=
t
> 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 file=
s
> fails.
>
> But if it is not a PHP timeout, what is it?
>
> 2010/3/26 Richard Quadling
>>
>> On 26 March 2010 12:21, Bastien Helders 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:
>> >
>> >
>> > zip warning: ../../build/Patch-6-3-2_Q3P15.zip not found or empty
>> >
>> > zip error: Internal logic error (write error on zip file)
>> >
>> >
>> > 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 cal=
l
>> > exec('zip -r ...'), then I only get:
>> >
>> >
>> > zip error: Internal logic error (write error on zip file)
>> >
>> >
>> > 2) The error messages of the second scenario doesn't surprise me much:
>> >
>> >
>> > zip error: Unexpected end of zip file (build/Patch-6-3-2_Q3P15.zip)
>> >
>> >
>> > Which was already known, as the call of copy() on the old patch P14 cr=
op
>> > 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=3DZEND002498&r=3D213=
474731
>> 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.ma x-execution-tim=
e)
Can you run the command from the shell directly without any problems.
And run it repeatedly.
--=20
-----
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=3DZEND002498&r=3D213474=
731
ZOPA : http://uk.zopa.com/member/RQuadling
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: Zip and text files generated are corrupted
am 27.03.2010 11:11:11 von Kim Madsen
Mike Roberts wrote on 25/03/2010 14:56:
> remove
No :-) Use the proper unsubscribe method rather than spamming the list.
--
Kind regards
Kim Emax - masterminds.dk
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: Zip and text files generated are corrupted
am 29.03.2010 10:17:03 von Bastien Helders
--0016364c77495b514d0482ec23d2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
>I'm not sure. What is the exact command you are using?
I'll show the code for the two scenario, maybe it'll help. I've edited out
the sensitive information though, but I kept the essence of how it works.
1) Copy the previous file and make modification on it
//This is this command that got interrupted and thus create the unexpected
end-of-archive
//To note is that the $previous_patch is retrieved from another file server
copy($previous_patch,$zipname);
//I go up in the file system, so that build/patchname doesn't appear in the
paths in the zip archive.
chdir('build/'.$patchname);
//Foreach new folder add it to the copied patch
foreach($folders_added as $folder){
$command =3D 'zip -gr ../../' . $zipname . '
software/hfFolders/'.$folder.'/* 2>&1';
exec($command, $output, $status);
//show output and status
}
//I go down again, as it is no more needed when deleting entry in a zip fil=
e
chdir('../..');
//Foreach folder to be removed, remove it
foreach($folders_removed as $folder){
$command =3D 'zip -d ' . $zipname . ' software/hfFolders/'.$folder.=
'\*
2>&1';
exec($command, $output, $status);
//show output and status
}
2)After all the needed files are gathered in a temporary folder, compress
the all
//I go up in the file system, so that build/patchname doesn't appear in the
paths in the zip archive.
chdir('build/'.$patchname);
$command =3D 'zip -r ../../' . $zipname . ' * 2>&1';
//This is the command that timeout in this case
exec($command, $output, $status);
//show output and status
//Do the rest of the operations
>I wonder if the zipArchive route would be easier.
That what I was using before, but it modifies the timestamp of the file tha=
t
are already in the zip archive and I can't have that.
>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=
)
Yeah I found this config in the httpd-default.conf file of my apache
installation, but as I determined using two consecutive call of microtime()
that the interrupted instructions doesn't go farther as 200 seconds, I don'=
t
see it relevant... (and again after the instruction is interrupted, the
script continue to run.)
>Can you run the command from the shell directly without any problems.
>And run it repeatedly.
I take that the equivalent of the php copy() function is the Windows copy
command line.
In this case, both copy on the big archive and zip -r on a big gathering of
folder are running in the shell without any problem and repeatedly.
2010/3/26 Richard Quadling
> On 26 March 2010 15:20, Bastien Helders wrote:
> > I have checked the rights on the file for the first scenario and no us=
er
> 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 a=
pp
> > 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 contin=
ue
> 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
> >>
> >> On 26 March 2010 12:21, Bastien Helders 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:
> >> >
> >> >
> >> > zip warning: ../../build/Patch-6-3-2_Q3P15.zip not found or empty
> >> >
> >> > zip error: Internal logic error (write error on zip file)
> >> >
> >> >
> >> > The funny thing is, that now it is throwing status 5: "a severe erro=
r
> in
> >> > the
> >> > zipfile format was
> >> > detected. Processing probably failed imme=ADdiately." 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:
> >> >
> >> >
> >> > zip error: Internal logic error (write error on zip file)
> >> >
> >> >
> >> > 2) The error messages of the second scenario doesn't surprise me muc=
h:
> >> >
> >> >
> >> > zip error: Unexpected end of zip file (build/Patch-6-3-2_Q3P15.zip)
> >> >
> >> >
> >> > 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=3DZEND002498&r=3D213474731
> >> 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-ti=
me
> )
>
> 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=3DZEND002498&r=3D2134=
74731
> ZOPA : http://uk.zopa.com/member/RQuadling
>
--=20
haXe - an open source web programming language
http://haxe.org
--0016364c77495b514d0482ec23d2--
Re: Zip and text files generated are corrupted
am 30.03.2010 14:04:57 von Bastien Helders
--0016e65b62923dbd130483037020
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
I've come to realize something, but I'm not sure if I could be right:
Maybe the instructions are interrupted because there is a lack of virtual
memory. I mean is there not a limit to the memory the script can use? It
would explain why the script goes on, as when the instruction is
interrupted, all the memory taken by it is released.
I don't know if I was clear about what I wanted to say...
2010/3/29 Bastien Helders
> >I'm not sure. What is the exact command you are using?
>
> I'll show the code for the two scenario, maybe it'll help. I've edited ou=
t
> the sensitive information though, but I kept the essence of how it works.
>
> 1) Copy the previous file and make modification on it
>
>
> //This is this command that got interrupted and thus create the unexpecte=
d
> end-of-archive
> //To note is that the $previous_patch is retrieved from another file serv=
er
> copy($previous_patch,$zipname);
>
> //I go up in the file system, so that build/patchname doesn't appear in t=
he
> paths in the zip archive.
> chdir('build/'.$patchname);
>
> //Foreach new folder add it to the copied patch
> foreach($folders_added as $folder){
> $command =3D 'zip -gr ../../' . $zipname . '
> software/hfFolders/'.$folder.'/* 2>&1';
> exec($command, $output, $status);
> //show output and status
> }
> //I go down again, as it is no more needed when deleting entry in a zip
> file
> chdir('../..');
>
> //Foreach folder to be removed, remove it
> foreach($folders_removed as $folder){
> $command =3D 'zip -d ' . $zipname . '
> software/hfFolders/'.$folder.'\* 2>&1';
> exec($command, $output, $status);
> //show output and status
> }
>
>
>
> 2)After all the needed files are gathered in a temporary folder, compress
> the all
>
>
> //I go up in the file system, so that build/patchname doesn't appear in t=
he
> paths in the zip archive.
> chdir('build/'.$patchname);
> $command =3D 'zip -r ../../' . $zipname . ' * 2>&1';
> //This is the command that timeout in this case
> exec($command, $output, $status);
> //show output and status
>
> //Do the rest of the operations
>
>
> >I wonder if the zipArchive route would be easier.
>
> That what I was using before, but it modifies the timestamp of the file
> that are already in the zip archive and I can't have that.
>
>
> >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-ti=
me
> )
>
> Yeah I found this config in the httpd-default.conf file of my apache
> installation, but as I determined using two consecutive call of microtime=
()
> that the interrupted instructions doesn't go farther as 200 seconds, I do=
n't
> see it relevant... (and again after the instruction is interrupted, the
> script continue to run.)
>
>
> >Can you run the command from the shell directly without any problems.
> >And run it repeatedly.
>
> I take that the equivalent of the php copy() function is the Windows copy
> command line.
> In this case, both copy on the big archive and zip -r on a big gathering =
of
> folder are running in the shell without any problem and repeatedly.
>
>
> 2010/3/26 Richard Quadling
>
>> On 26 March 2010 15:20, Bastien Helders 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 delet=
e
>> it
>> > if I wanted.
>> >
>> > For the second scenario, it doesn't even apply, as the exec('zip') tha=
t
>> > 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
>> >>
>> >> On 26 March 2010 12:21, Bastien Helders
>> 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:
>> >> >
>> >> >
>> >> > zip warning: ../../build/Patch-6-3-2_Q3P15.zip not found or empty
>> >> >
>> >> > zip error: Internal logic error (write error on zip file)
>> >> >
>> >> >
>> >> > The funny thing is, that now it is throwing status 5: "a severe err=
or
>> in
>> >> > the
>> >> > zipfile format was
>> >> > detected. Processing probably failed imme=ADdiately." 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:
>> >> >
>> >> >
>> >> > zip error: Internal logic error (write error on zip file)
>> >> >
>> >> >
>> >> > 2) The error messages of the second scenario doesn't surprise me
>> much:
>> >> >
>> >> >
>> >> > zip error: Unexpected end of zip file (build/Patch-6-3-2_Q3P15.zip)
>> >> >
>> >> >
>> >> > 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=3DZEND002498&r=3D213474731
>> >> 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-t=
ime
>> )
>>
>> 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=3DZEND002498&r=3D213474731
>> ZOPA : http://uk.zopa.com/member/RQuadling
>>
>
>
>
> --
> haXe - an open source web programming language
> http://haxe.org
>
--=20
haXe - an open source web programming language
http://haxe.org
--0016e65b62923dbd130483037020--