When saving files to the hard drive on windows using any of the sys.io.File write() functions UNWANTED extra bytes get added as you can see in the screenshot. Not so much of an issue for text files, but a massive issue for audio files and anything else that requires the bits to be where they are supposed to be! Also created a github issue.
Some Setup Info:
haxe 3.2.1
next
Do you open file in binary mode?
Hello 
The updated ByteArray uses haxe.io.Bytes underneath. The positive is we can convert to/from haxe.io.Bytes with practically no overhead cost, but this does expose a little bit of our internal logic – and causes a problem here.
In order to optimize against byteArray.writeInt (0); and other repeated writing, we allocate a larger size than you need internally. This doesn’t really use extra memory (due to block size) and results in better performance, but oh, what if you want to write or flush your bytes?
I think there might be a clever solution to this, hopefully without causing an allocation. One idea is that the toBytes conversion for the ByteArray abstract could (perhaps?) modify the underlying length value. I think this might work (even though the real buffer is larger), and cause it to behave with haxe.io.Bytes APIs.
Worst case, casting to/from haxe.io.Bytes then writing again causes another (technically unneeded) allocation, but the value of being able to File.saveBytes (byteArray); outweighs that
EDIT: I think I got it: https://github.com/openfl/openfl/commit/0433654517dff7ac57c1cf0d550d24cc1d644dc3
