Edit report at http://bugs.php.net/bug.php?id=40494&edit=1
ID: 40494
Comment by: yubingyujuan at 163 dot com
Reported by: foster dot graeme at gmail dot com
Summary: Memory problem with ZipArchive::addFile()
Status: Bogus
Type: Bug
Package: Zip Related
Operating System: Linux
PHP Version: 5.2.1
Assigned To: pajoye
New Comment:
I get an empty zip file whene I use ZipArchive::addFile.
Previous Comments:
------------------------------------------------------------------------
[2007-02-15 16:14:03] paj...@php.net
Yes, it can be added to the doc.
However your explanation is not correct. The files are open and kept
open until the archive is closed (that's why you reach the handlers
limit). It is the only safe way to lock a file and be sure it exists
when when we finalize the archive.
------------------------------------------------------------------------
[2007-02-15 15:15:13] foster dot graeme at gmail dot com
Would it be possible to add a brief description of this situation to the
documentation, for example the following could be added to the
description of ZipArchive::addFile
Description
bool ZipArchive::addFile ( string filename [, string localname] )
Adds a link to the ZIP archive from a given path. When the archive is
closed the link is checked to ensure that the file still exists and will
then be compressed and added to the archive. If a lot of files are being
added then the number of file handles permitted by the OS may be
exceeded, if that occurs then the status will be set to
ZIPARCHIVE::ER_OPEN. This can be avoided by closing the archive before
the limit is reached and then reopening the archive.
for example:
if ($zip->numfile % $limit == 0)
{
$zip->close();
$zip->open($filename,ZIPARCHIVE::CREATE);
}
------------------------------------------------------------------------
[2007-02-15 14:35:34] paj...@php.net
"I still think that it would be nice if there was some way for the
system to manage this."
It is in the TODO list. As I said three times already in this
discussion. The solution is to add different modes:
- commit at the end when the archive is close
- immediate addition (will be much slower)
And again, it is in my TODOs already. I cannot tell when they will be
available (I do it on my free time).
In the meantime a simple:
if (($zip->numFiles % $yourlimit) == 0) {close; reopen;}
will do it.
"the archive can be partially built prior to the ulimit being reached.
This could be set as 250, with the ability to overload it. Maybe this
would only be triggered if a flag was set when the archive was opened."
This solution does not work.The limit is arbitrary. There is no way to
get an exact value (and I doubt php is the only running process).
------------------------------------------------------------------------
[2007-02-15 14:02:51] foster dot graeme at gmail dot com
Okay thanks for the explanation, I understand the problem a little
better. I still think that it would be nice if there was some way for
the system to manage this.
I was thinking along the lines of a function to flush the files so that
the archive can be partially built prior to the ulimit being reached.
This could be set as 250, with the ability to overload it. Maybe this
would only be triggered if a flag was set when the archive was opened.
------------------------------------------------------------------------
[2007-02-15 13:23:36] paj...@php.net
See:
http://pecl.php.net/bugs/bug.php?id=9443
"it would be good if this wasn't necessary, in thatthe code could catch
the problem and allocate extra file handles if that is the problem."
This is not something I can control. The operating system defines it and
there is no way for me to increase this value.
I suggest you to close and reopen it every 1000 or so (or even 255 if
you want to go on the safest way, ie old windows).
Future releases will have a different mode, where the checks will done
only when you close the archives.
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/bug.php?id=40494
--
Edit this bug report at http://bugs.php.net/bug.php?id=40494&edit=1
