RFR 8023173: FileOutputStream(FileDescriptor) does not respect append flag on Windows
Alan.Bateman at oracle.com
Fri Oct 17 09:00:15 UTC 2014
On 06/10/2014 11:41, Ivan Gerasimov wrote:
> Hello everybody!
> The append mode is emulated on Windows, therefore we have to keep a
> flag indicating that.
> With the current implementation, the FileDescriptor does not know if
> the file were opened with O_APPEND, and the flag is maintained at the
> upper level.
> This can cause inconsistency, when the FileDescriptor is reused to
> construct a new FileOutputStream, as there is no information available
> about the append/non-append mode.
> Even though the solution is quite straight-forward: moving the flag
> from FileOutputStream, FileDispatcherImpl and FileChannelImpl to the
> lower level of FileDescriptor, it touches 20 files across the
> source-code base.
> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8023173
> WEBREV: http://cr.openjdk.java.net/~igerasim/8023173/0/webrev/
> With the fix, all the io/nio tests, including the new one, pass on all
> available platforms.
> Would you please help review this fix?
Martin prodded me a few times but I was busy with other things and only
getting to this now.
At a high level then moving the append down to FileDescriptor make sense
but I have a few concerns.
On Unix systems then it looks like getAppend is calling into the ioctl
to get the file descriptor flags. If I read it correctly then it creates
several problems for the usage in FileChannelImpl.position. I just
wondering if you consider just leaving the append flag there and just
retrieve the value once in the open method.
I'm also wondering about the handleWrite implementation on Windows which
changes to use additional JNI to retrieve the value of the append flag
each time. We should try to avoid this (we want the native methods to be
as simple as possible so that we can replace them in the future) so
there may be an argument for passing that down as per the current
More information about the core-libs-dev