RFR 8023173: FileOutputStream(FileDescriptor) does not respect append flag on Windows

Alan Bateman 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 mailing list