Xojo BinaryStream

Dim b As BinaryStream
Dim f As FolderItem
b = binarystream.create(f,True)

I don’t understand “CREATE”…
If I leave off “True”… I get file errors… If I don’t then I can write to the file…
and if I set a position greater than the file size, it pads the file with zeros
If I use OPEN with readwrite TRUE it seems to be the same as CREATE with Overwrite=True

So is this correct?

* 1] b.Open(path, false) ... file must exist and is READ ONLY
* 2] b.Open(path,true) ...   file must exist and is Read/Write... and attempt to read past EOF, pad out the file with zeros
* 3] b.Create(path,false) ... same as #2
* 4] b.Create(path,true) ... creates file if not exists, then same as #2

Also… .in typical Xojo fashion, the docs refer to a WriteByte function. There is NO such function. you must use WriteInt8 or WriteUint8

create(folderitem,_ overwrite :  false)
     If the file already exists, an exception is raised
     otherwise creates the file, and continues as if open(folderitem,readwrite:true)

create(folderitem,_ overwrite :  true)
      Truncates an existing file, or creates a new one if not exists,
      then continues as if open(folderitem,readwrite:true)

open(folderitem,_ readWrite : false) {
       raises an exception if file does not already exist otherwise file is READ ONLY

open(folderitem,_ readWrite : true) {
       raises an exception if file does not already exist otherwise file is READ/WRITE

Thanks go out to Tim Parnell for helping me test/verify these situations

As an old OS programmer, I find this interesting. Back when I was doing ProDOS 1.1.1 for the Apple II we had major discussions on sparse files. Basically, if you write non-contiguous data to a file, ProDOS wouldn’t waste disk space with empty blocks. So if you wrote to position 1 in the file and then wrote to position 1,000,000, the system would only allocate those two blocks on the drive. Of course, with today’s super-fast multi-terrabyte drives, parse files aren’t really necessary but, back then, being able to write a 1 meg file to a 143K disk was possible.

expect a BinaryStream isn’t a sparse file… If you write something to position 1,000,000 if needs to be able to read it from the same place. I used ProDos in the past, but don’t recall what it did, but there was more of an urgency to be sparse, when most people were limited to small floppy disks,unless you were uber rich and had a HDD

But suffice to say, my Swift BinaryStream class operates in EXACTLY the same way as the Xojo one does.

Seems Prodos used a link list type of filesystem…


I never saw sectors on a ProDOS volume. ProDOS volumes are very simple to understand while modern OS are… complex !

Also, just like ProDOS (son of DOS, “brother“ of SOS), Xojo comes from… more than 20 years of developments.

So, decisions from the past can still be in Xojo and may look - now - strange when you look at them in 2021.