Thank you Sven.

I an trying to read a veeeery long log file, and extract the last 5 messages for the user to see them. Reading the whole file from the beginning is too expensive. So maybe I could try reading backwards from the end using binary mode and look for a lf... I have to think about it a little bit, and study your proposal, of course.

2014-11-17 9:26 GMT+01:00 Sven Van Caekenberghe <sven@stfx.eu>:

Hi Jos��,

> On 17 Nov 2014, at 02:06, Jos�� Comesa��a <jose.comesana@gmail.com> wrote:
>
> There is an annoying error in MultiByteFileStream, reading back when you have a unicode character. It is also the cause of some FileOut errors. Your can reproduce it this way:
>
> testString := 'abcd��'.
> filename := 'test.txt'.
> filename asFileReference ensureDelete.
> filename asFileReference
>�� �� �� �� �� �� �� ��writeStreamDo: [ :stream |
>�� �� �� �� �� �� �� �� �� �� �� ��stream
>�� �� �� �� �� �� �� �� �� �� �� �� �� �� �� ��nextPutAll: testString ].
>
> f := 'test.txt' asFileReference readStream.
>
> f setToEnd.
>
> f skip: -1.
>
> f peek.
>
>
> Any ideas how to solve it? Avoiding reading back is not an option ;). Maybe making skip to go back one more byte to check if there is a unicode character around?.
>
> Thanks a lot.

This is a known problem/issue/limitation of MultiByteFileStream and the TextConverters.

The more modern/logical ZnCharacterEncoders can do this reliably (provided the underlying stream can itself move backwards and the current position is between whole characters).

'test.txt' asFileReference readStreamDo: [ :in |
�� in binary; setToEnd.
�� ZnUTF8Encoder new backOnStream: in; nextFromStream: in ]

IMHO, the ability to move backwards and to play with positions without restrictions on streams only makes sense with in-memory streams, not with file or network streams. It plays badly with buffering too.

I know this doesn't solve your issue but I hope it gives you a better idea of the situation.

Where exactly do you have this issue ?

Sven