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).

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/

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)

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.

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

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.