Wrong write bytes with macosX64 target

[FirstAM]

Problem

Error copy file via kotlinx-io, ( copy bytes from one file to another)
in my case i have different size of files

-rw-r--r--@  1 user  LD\Domain Users  593521 Oct 22 17:57 test.zip
-rw-r--r--@  1 user  LD\Domain Users  589824 Oct 22 17:57 test1.zip

How to reproduce:

val filePath = Path("somePathToOldFile")
val bytes = SystemFileSystem.source(filePath).buffered().readByteArray()
SystemFileSystem.sink( Path("$projectPath/newFile")).buffered().write(bytes)

At the moment i can reproduce it only with macOS targest ( don't have the linux machine )

kotlin-io.zip
Or use unpack archive and do

./gradlew linkDebugExecutableMacosX64
chmod +x ./Projects.kexe
./Projects.kexe

[JakeWharton]

You need to use a use on your sink. The buffered bytes are not being flushed.

SystemFileSystem.sink( Path("$projectPath/newFile")).buffered().use { sink ->
  sink.write(bytes)
}

[JakeWharton]

You should also use the source(), to be clear, as you'll leak a file handle otherwise while the process is alive, but it doesn't impact the correctness of the copy, technically.

[FirstAM]

@JakeWharton
Thank you for answer, in this situation I can see at least two conclusions:

1. solution with use not documented and not explicit for consumer. So, how should I have guessed that i have to use it ?
2. buffered function return RealSink than implements Sink, so solution with use seems strange for me as consumer to
3. The The buffered bytes are not being flushed. seems, for me as consumer as bug source/sink interfaces. Because if you use jvm target in my example, you don't meet same problem with buffer

[fzhinkin]

solution with use not documented and not explicit for consumer. So, how should I have guessed that i have to use it ?

Fair enough, the documentation could definitely be improved here.

buffered function return RealSink than implements Sink, so solution with use seems strange for me as consumer to

Could you please elaborate why that seems strange?

The The buffered bytes are not being flushed. seems, for me as consumer as bug source/sink interfaces. Because if you use jvm target in my example, you don't meet same problem with buffer

Assuming the same number of bytes were written into a Sink that was not closed, the behavior is the same across all the targets.