#40494 [Asn->Bgs]: Memory problem with ZipArchive::addFile()

ID: 40494 Updated by: pajoye@php.net Reported By: foster dot graeme at gmail dot com -Status: Assigned +Status: Bogus Bug Type: Feature/Change Request Operating System: Linux PHP Version: 5.2.1 Assigned To: pajoye New Comment: "When adding files to an archive, (using successive ZipArchive::addFile() commands) the compression doesn't happen until the file is closed. " Yes, we do it while finalizing the archive. " This can result in an out of memory error, " You will run out of file ID before running out of memory. It does not really use many memory, only the file names and file handlers. I suppose you are talking about the file handlers? "It would certainly require a rewrite of the ugly function zip_close()" What is ugly in this function? Or do you have a portable way to lock a file until the archive creation is done? I think you refer to the file handlers limitation. There is already a bug about it and I plan to add a special (less safe) mode. This mode will allow one to add only the paths without checks, errors will occur only when the archive is closed. But that's a feature addition not a bug fix. I close this bug (not a bug > bogus). Thanks for your report! Previous Comments: ------------------------------------------------------------------------ [2007-02-15 10:22:25] foster dot graeme at gmail dot com Description: ------------ When adding files to an archive, (using successive ZipArchive::addFile() commands) the compression doesn't happen until the file is closed. This can result in an out of memory error, a temporary fix is to close the archive and then reopen it within the php code. An idea solution would be to compress the file when it is added, probably in function _zip_replace(), but I don't know what the implications of this would be. It would certainly require a rewrite of the ugly function zip_close(). ------------------------------------------------------------------------ -- Edit this bug report at http://bugs.php.net/?id=40494&edit=1