In a separate email I suggested deprecating FileReference>>openWritable: (I'm still planning to submit a PR), but on further inspection... Does anyone know the history and plans for File and FileHandle? The comments for FileHandle to me suggest it is a layer between a stream and the primitives (FilePlugin). But as far as I can tell, it is never used. The stream creation methods in FileReference (readStream, writeStream, binaryReadStream, binaryWriteStream) use FileHandle during the stream creation, but the end result doesn't actually include a FileHandle. The main method called (in the case of the write variants) is: -- FileHandle>>binaryWriteStream ^ (File named: reference fullName) writeStream -- which obviously doesn't actually need FileHandle at all. Streams have a handle, but it is a ByteArray, which is the associated SQFile structure used by the VM. Presumably the intention was that the streams would hold on to a FileHandle, which would keep the ByteArray. This makes sense since it gives us an object that can take responsibility for some operations (as opposed to using a ByteArray as the handle). On the other side, the class comment for File says: -- I represent a sequential binary File. I provide the minimum operations to: - move the cursor fo the file - reading - writing ... -- And then goes on to mention several methods that aren't actually implemented, e.g. seekAbsolute:, seekRelative:, nextPutAll:, next:, etc. It ends up just being a set of utility methods to facilitate the creation of streams. It would be great if someone is able to fill in the gaps. If not, I can think of two paths we can take (apart from leaving things as they are, which seems a bit messy): 1. Remove (deprecate) both File and FileHandle and move the responsibility of creating the BinaryFileStream to the FileSystemStore. 2. Make FileHandle really responsible for representing an open file and modify streams, etc., to use FileHandle. I prefer the second approach as it provides more granular responsibility and a natural place to put functionality that is not directly stream related (as an example, I'm planning to extend the file attributes functionality so we can stat() an open file to find out the mode, etc.). But I'd want to think about the performance implications of adding a layer between streams and FilePluginPrims. What am I missing? Cheers, Alistair