Hello all, Dolphin's streams signal errors on exhaustion, with a few clear exceptions. I quickly learned to appreciate the clarity. If I tell a stream to read 10 bytes, there is probably a reason for it, and I might want to be alerted if there are not that many bytes remaining, or in the case of a socket, I might want it to wait until there are that many or until the connection is broken. If a file cannot be opened, I want to know then, rather than after the offending method has returned and I have to hunt down what went wrong. What is you want at most ten bytes? There is a way to get that: #nextAvailable:. It and friends offer clear permission from you the programmer to the computer to truncate and return. This approach sometimes requires an #atEnd check or two, but it is worth the effort. I have described the problems and solutions here: http://code.google.com/p/pharo/wiki/ProposalForConsistentStreamsBehavior http://code.google.com/p/pharo/wiki/StreamsForRobustSoftware #next is not portable, and is IMHO just plain broken on Squeak, Pharo, and VW. #next: does not work as advertised on some platforms. But there is nothing to stop me (and you) from writing code in terms of selectors such as #nextOne and #nextMany:. It is some extra typing, but it can be done now: I've been doing it the entire time I have made serious use of Pharo. I am *STILL* finding places in which file streams do annoying things (such as prompting "the user" on my server [argggggg!!!!!!<g>], but I will eventually identify them and code around them. Consider this preliminary, but here is some code: http://squeaksource.com/PharoInbox/DolphinCompatibility-Streams-BillSchwab.1... Bill