|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Request #58727 Better handling of OS limitations / stability
Submitted: 2009-06-17 17:30 UTC Modified: 2014-12-30 10:41 UTC
Avg. Score:5.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:0 (0.0%)
Same OS:1 (100.0%)
From: sweiss at stylesight dot com Assigned:
Status: No Feedback Package: zip (PECL)
PHP Version: 5.2.9 OS: Linux
Private report: No CVE-ID: None
Have you experienced this issue?
Rate the importance of this bug to you:

 [2009-06-17 17:30 UTC] sweiss at stylesight dot com
As many have noted, the zip extension does not handle at all 
managing the 
various OS-dependent limits which govern the zipping process 
(max open 
file descriptors or max memory available).  Basically, the 
seems set up to fail unless the developer writes in basic 
error checking 
and control themselves.  However, options are not really 
available to the 
developer to handle these limits in an effective manner.  In 
our current 
situation, we need to be able to zip a virtually unlimited # 
of files and 
streams into one file.  While we can monitor limits and 
close and reopen 
the file to get around them, this is very taxing on the 
servers - when 
your storage is on NFS, and you tell the server to close a 
6GB zip file 
and then reopen it to continue, multiple times in one 
operation... this 
has actually brought my site to a standstill a couple times 
now and as 
such we are now considering switching the entire download 
facility to 
ruby, whose rubyzip extension does not require such drastic 

If you're not going to automatically handle limits like 
memory and file 
descriptors, please provide a function which allows us to 
flush changes 
to disk (as if a close were happening) while holding the zip 
file open 
for further changes.

This must be possible, otherwise no zip software in 
existence would be 
able to create such a large zip file without closing and 
repeatedly (yet, they can - in fact, this PHP extension is 
the only zip 
software I know of with such limitations, even compared to 
extensions for other languages).  It is very frustrating 
that PHP 
continues for so long to have these issues, even while 
offering a zip API 
that has so many other features (many of which, while I'm 
sure are well 
intentioned, aren't really nearly as important as a stable 
which does not regularly cause fatal errors or max out 
bandwidth).  Please throw us a bone and add just this one 
method so my 
poor server's NIC can struggle just a little less.


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2013-10-23 14:43 UTC]
-Status: Open +Status: Feedback
 [2013-10-23 14:43 UTC]
Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read for *NIX and for Win32

Once you have generated a backtrace, please submit it to this bug
report and change the status back to "Open". Thank you for helping
us make PHP better.

This bug report is very old.

The zip extension is "only" a wrapper for libzip where default behavior is to write change to disk on close command.

The open file limit seems to not be a problem anymore. I can create an archive with ~11000 files without raising any error (max open files = 1024).

If libzip library introduce a new behavior (like a "commit" function), this new feature will be available in this extension (so probably you need to ask libzip upstream about that).

Despite, as a workaround exists (closing/reopening), I propose to close this one.
 [2014-12-30 10:41 UTC] pecl-dev at lists dot php dot net
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Re-Opened". Thank you.
PHP Copyright © 2001-2023 The PHP Group
All rights reserved.
Last updated: Fri Jun 02 08:03:37 2023 UTC