Ilia Alshanetsky wrote: > Greg, > > First of great job on the analysis of the problem. As far as I can > tell (correct me if I am wrong) the problem lies in extraordinary > complex use of stream filters, with >2 stacking > such as phar://zip://bz2:// (for example). Since I'd wager that this > is not a common use care, I would prefer to refrain from any major > changes for this for the 5.2 release. Whatever simple solutions we can > implement such as fix for #1 (which appears to have already been > committed) are more then welcome, however my call is that #2 and #3 > wait for 5.3, unless a simple and reliable solution is found.
Hi Ilia, Actually, I ran into the problem when using a single stream filter on a file that contained uncompressed data after the compressed data. When filling the read buffer, PHP tries to load in an arbitrary number of bytes. The bz2 and zlib filters were failing because they would continue to attempt to process data after the underlying library (libbz2 or libzlib) would tell it that it was done, triggering an error. The bug in bz2/zlib was fixed today, but the problem remains - php is passing in more data to stream filters than it should, as it is never safe to assume that this is an OK thing to do. The problem of chaining filters is an example I doubt anyone has actually tried. The same problem exists if one appends a filter to decompress some data, and then use fseek on the filtered data when not all of the data has been decompressed (which is actually a typical use case and one I ran into today). To be clear, although the example was inside the phar extension, it uses a file-based stream and stream_filter_append() with bzip2.decompress stream filter to decompress the contents of a file within a zip archive, no use of the zip:// stream is done inside the phar extension. However, I think it is safe to assume nobody has tried this, as we would have had a bug report before I ran into it today, so I'm fine with fixing it in 5.3 unless this new information makes you think it is a critical addition to 5.2 since it is essentially broken. Greg -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
