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.

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

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.

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

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.

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.

"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 :)