FileSystem.sink has no ability to create new files atomically (POSIX O_CREAT | O_EXCL, Win32 CREATE_NEW, Java StandardOpenOption.CREATE_NEW). This feels like fairly fundamental functionality for a file I/O library, and is currently the sole reason I am unable to use kotlinx.io over java.nio in an application.
I would propose adding another keyword argument to FileSystem.sink to specify whether an existing file should be overwritten. This parameter would allow the implementation to use an appropriate set of flags when creating the file to ensure the file is created atomically, or could throw an exception if atomic creation is unsupported on a given platform. This parameter could default to true in order to preserve existing behavior in the API, or default to false to provide a safer default behavior:
FileSystem.sinkhas no ability to create new files atomically (POSIXO_CREAT | O_EXCL, Win32CREATE_NEW, JavaStandardOpenOption.CREATE_NEW). This feels like fairly fundamental functionality for a file I/O library, and is currently the sole reason I am unable to usekotlinx.iooverjava.nioin an application.I would propose adding another keyword argument to
FileSystem.sinkto specify whether an existing file should be overwritten. This parameter would allow the implementation to use an appropriate set of flags when creating the file to ensure the file is created atomically, or could throw an exception if atomic creation is unsupported on a given platform. This parameter could default totruein order to preserve existing behavior in the API, or default tofalseto provide a safer default behavior:This change would allow files to be created without risk of a race condition causing files to be overwritten unexpectedly.