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:
Do you open file in binary mode?
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
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