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

[Alan Bateman]

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.

-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20191120/af504ba8/attachment.html>