Bug #49874 [Com]: ftell() and fseek() inconsistency when using stream filters

Edit report at https://bugs.php.net/bug.php?id=49874&edit=1 ID: 49874 Comment by: phofstetter at sensational dot ch Reported by: jketterl at chipxonio dot de Summary: ftell() and fseek() inconsistency when using stream filters Status: Open Type: Bug Package: Filesystem function related Operating System: linux (ubuntu) PHP Version: 5.5.4 Block user comment: N Private report: N New Comment: This is an inherent problem with all filters that keep internal state (which is probably all but the simplest): There's no way a filter can learn about seeking on the underlying stream and thus it can't reset its internal state. It's a tricky problem though: For any seek() but a seek() going to the beginning of the stream, it's pretty much impossible to correctly rebuild the internal filter state after seeking on the stream. I think what should happen in order to save other people the trouble in the future is to mark streams with filters attached as non-seekable. Previous Comments: ------------------------------------------------------------------------ [2018-07-08 10:14:49] php at bohwaz dot net Same issue with zlib: <?php $fh = fopen('php://temp', 'w+'); fwrite($fh, '123'); var_dump(ftell($fh)); stream_filter_append($fh, 'zlib.deflate', STREAM_FILTER_WRITE, 9); fwrite($fh, 'abc'); var_dump(ftell($fh)); fseek($fh, 0); var_dump(fread($fh, 1024)); fclose($fh); ?> Will return: int(3) int(3) string(3) "123" See: https://3v4l.org/VAfmR ------------------------------------------------------------------------ [2017-08-01 12:06:31] paul dot smith at deepseaplc dot com I'm also having this problem with the zlib.deflate filter in PHP 5.6.20. I attempted to append a user filter after zlib.deflate with the intention of totalling the datalen of the buckets. The filter() function is called but stream_bucket_make_writeable($in) returns null. I suspect this is related to the ftell problem. ------------------------------------------------------------------------ [2013-10-24 08:19:46] yohgaki@php.net It seems 5.5 has this problem still string(8) "Line 01 " string(8) "Line 02 " string(8) "Line 01 " string(5) "e 01 " [yohgaki@dev php-5.4]$ php -v PHP 5.5.4 (cli) (built: Sep 19 2013 13:06:40) ------------------------------------------------------------------------ [2009-10-15 06:54:31] jketterl at chipxonio dot de thanks for having a look i tried with and without. the challenge is to get it working without, because that's the worst case my app has to deal with, but the BOM doesn't seem to solve this. $ hexdump test-with-bom.csv 0000000 feff 004c 0069 006e 0065 0020 0030 0031 0000010 000a 004c 0069 006e 0065 0020 0030 0032 0000020 000a 004c 0069 006e 0065 0020 0030 0033 0000030 000a 004c 0069 006e 0065 0020 0030 0034 0000040 000a 0000042 $ php test.php string(8) "Line 01 " string(8) "Line 02 " string(8) "Line 01 " string(5) "e 01 " i also tried opening the file including the BOM without a stream filter, but that just resulted in php reading in two extra chars (the BOM converted in some way i guess) on the beginning of the first line. i thought i'd attach the sample files to this bug, but it seems like i can't. i've uploaded them here instead: http://www.djmacgyver.net/tmp/php-ftell/ ------------------------------------------------------------------------ [2009-10-14 16:40:00] Sjoerd@php.net Thank you for your bug report. Does your test.csv file start with a BOM? You can determine this by viewing the file in a hex editor. If it starts with fffe or feff, it has a BOM (byte order mark). ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=49874 -- Edit this bug report at https://bugs.php.net/bug.php?id=49874&edit=1