php.net |  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
Votes:1
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
 [2009-06-17 17:30 UTC] sweiss at stylesight dot com
Description:
------------
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 
extension 
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 
workarounds.

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 
reopening 
repeatedly (yet, they can - in fact, this PHP extension is 
the only zip 
software I know of with such limitations, even compared to 
other 
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 
extension 
which does not regularly cause fatal errors or max out 
storage 
bandwidth).  Please throw us a bone and add just this one 
method so my 
poor server's NIC can struggle just a little less.


Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2013-10-23 14:43 UTC] remi@php.net
-Status: Open +Status: Feedback
 [2013-10-23 14:43 UTC] remi@php.net
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
http://bugs.php.net/bugs-generating-backtrace.php for *NIX and
http://bugs.php.net/bugs-generating-backtrace-win32.php 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-2024 The PHP Group
All rights reserved.
Last updated: Sat Dec 21 16:01:28 2024 UTC