[RFC] 4950302: (fs spec) Random write produces different results on Linux vs Windows from same .class

[David Lloyd]

On Wed, Nov 20, 2019 at 3:01 AM Alan Bateman <Alan.Bateman at oracle.com> wrote:
>
> On 20/11/2019 00:06, Brian Burkhalter wrote:
>
> This issue [1] is caused by a Linux bug documented in the pwrite(2) man page [2]:
>
>         POSIX requires that opening a file with the O_APPEND flag should have
>         no effect on the location at which pwrite() writes data. However, on
>         Linux, if a file is opened with O_APPEND, pwrite() appends data to the
>         end of the file, regardless of the value of offset.!
>
> One possible fix is [3] where if O_APPEND is set, it is unset to make the pwrite() call and then reset. This of course could be problematic if another thread were writing to the same file descriptor simultaneously: not all uses of IOUtil.write() use exclusion locks. But maybe this is better than the current situation? It was verified to fix the problem shown by the reproducer included in the issue description.
>
> The write method is performance critical so I don't think we want this. Also changing the append mode mid-flight will impact other methods on the channel that can execute concurrently with the write. In general, it's a bit strange to open a file for append and then try to do positional writes. If someone really wants to do that they can they create two FileChannels of course. If we have to do anything then it could be worked around in FileChannelImpl where you can know if the file is opened for append and can coordinate with other operations on the channel.

If toggling the mode is unacceptable, an
also-not-so-great-but-should-work alternative workaround would be to
open `/proc/self/fd/<fdnum>` and write to that (basically this works
more or less like dup() but doesn't share file offset and flags).
Then you're not toggling file modes - though it will of course fail if
you run out of file descriptors.

-- 
- DML