All in all the switch to FileSystem is very good. File/Directory manipulation is much improved. (But it does create a problem for library/framework writers, like me, that want to remain compatible with 1.3 and 1.4) However, when trying to actually use FileSystem and when looking at the current users in the image, I see a problem (coming up) with FIleSystemStreams and its subclasses. They should be binary, but they are silently used as character based, either relying on implicit conversions or explicit ones, without proper encoding. This is wrong. Why is there a FileSystemReadStream>>#nextLine ? Why is there no FileSystemReadStream>>#next:into:startingAt: the cornerstone of efficient input ? Why are there FileSystemWriteStream>>#[tab|space|cr|crlf|lf â¦] methods on a binary stream ? Because even with these methods that should not be there, the streams opened by FileSystem cannot be used for simple parsers or renderers, simply because the elementary #next and #nexPut: deal with bytes instead of characters. Some time ago, I did a quick experiment by adding ZnCharacterReadStream and ZnCharacterWriteStream to Zn (in a later version than what is in 2.0, I include a file out) that solve this problem from my perspective (but they don't allow arbitrary #position[:] hacks). Another question is how buffering works (if present at all), since it seems to be hidden in the plugin ? What do the FileSystem hackers, Cami, Sean, et al, think about this situation ? Sven