php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #57393 ::addFile() leaks file handles
Submitted: 2006-11-24 10:19 UTC Modified: 2006-11-25 13:02 UTC
From: indeyets at gmail dot com Assigned: pajoye
Status: Duplicate Package: zip (PECL)
PHP Version: 5.1.6 OS:
Private report: No CVE-ID:
 [2006-11-24 10:19 UTC] indeyets at gmail dot com
Description:
------------
When adding files to archive, the process stops at file 252 (actually depends on ulimit)

Reproduce code:
---------------
<?php
// THIS IS "test.php"
$file = realpath('./test.php');

$zip = new ZipArchive();
$zip->open('test.zip', ZIPARCHIVE::CREATE);
for ($i = 0; $i < 1000; $i++) {
    $res = $zip->addFile($file, 'test'.$i.'.php');
    if (false === $res)
        die("oops @ ".$i."\n");
}
$zip->close();
unlink('test.zip');

echo 'done'."\n";


Expected result:
----------------
done

Actual result:
--------------
oops @ 252

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2006-11-24 10:28 UTC] pierre dot php at gmail dot com
Which OS? Windows has such limits by default, unices limits are higher and can be increased.

However, there is no way to increase this limit. And there is no other safe way to keep files intact until the script close the archives.

What I suggest is to close the archive and reopen it:

if ($filescnt%255==0) {close/reopen}

see #8714 for more details.
 [2006-11-24 10:36 UTC] indeyets at gmail dot com
it is unix with limit of 256
increasing a limit is not an option.

I see 3 solutions:
1) zip-extension should add files synchronously (probably, using some temporary file)
2) similiar to (1), but flush happens at some point, when ulimit for opened files is still not exhausted
3) you add an option, which makes zip-extension to be naive and believe, that files are going to stay where they are.

IMHO: application shouldn't be doing this tricks manually. problem should be solved inside of extension
 [2006-11-24 12:39 UTC] pierre dot php at gmail dot com
The zip is actualized on close, not live. There is no way to safely lock files (or be sure they are not deleted/removed/moved) before the closing operation. 

If you use unix in as server and you have a 255 limit, well, I cannot do much for you.

About 1. We already use temp files and keep them open (for good reasons like the one I said).

2., it is not a flush problem but about the amount of files handle, you have the exact same problem with any other applications.

About 3., it is *not* something I can control, the OS does it. I have no idea how many files are currently used by your process.

Short version: do the trick. There is no other way yet. Thanks for your understanding.
 [2006-11-25 12:19 UTC] indeyets at gmail dot com
I understand that.
That's why I propose you in (3) to add a flag, which will allow me to have "unsafe" behavior.


and regarding (1)/(2) I am saying not about using temporary files for the ones, which are going to be added, but about using temporary file for resulting archive, which will automatically be "closed/reopened" before ulimit is totally used.
and on manual close, it will just be moved on the place where archive is expected to be
 [2006-11-25 12:40 UTC] pierre dot php at gmail dot com
I will not add this flag, it is tricky and ugly and can add more troubles than solution. The current limitation is done by your operating system. Increase it if you need more, just like with any other application (as you are on unix, you can do it). If you do not want to increase it, check it yourself and close/reopen the archive.

On the good news side, it is planed to add method to add a directory, a pattern based selection of files or an array of files, which will really access them only when the archive is created, sequentially. That will solve your problem.
 [2006-11-25 12:48 UTC] indeyets at gmail dot com
ok. then I am waiting for those functions. thanks :)

the reason this bug was started by me: I believe, that programming using high-level language like PHP shouldn't be OS-dependent, or OS-configuration dependent. that's all. I believe it is the task of runtime to take care of such issues.
 [2006-11-25 13:02 UTC] pierre dot php at gmail dot com
"the reason this bug was started by me: I believe, that programming using high-level language like PHP shouldn't be OS-dependent"

As far as it is possible, I do it. There is already many OS specific hacks in the zip codes (mostly to make windows behaves normally), but it is not always possible :)
 
PHP Copyright © 2001-2014 The PHP Group
All rights reserved.
Last updated: Fri Apr 25 09:01:45 2014 UTC