RFR 8204310 : Simpler RandomAccessFile.setLength() on Windows

Alan Bateman Alan.Bateman at oracle.com
Wed Jun 6 13:57:06 UTC 2018


On 05/06/2018 07:23, Ivan Gerasimov wrote:
> Hello!
>
> When a file size is modified via RandomAccessFile.setLength(int) on 
> Windows, it is currently done in three steps:
>
> SetFilePointer(), SetEndOfFile(), SetFilePointerEx().
>
> First two can be combined in one call of SetFileInformationByHandle(), 
> which will make the code shorter and more aligned with Unix variant 
> (ftruncate64 is used on Unix systems, which behaves close to 
> SetFileInformationByHandle(_,FileEndOfFileInfo,_)).
>
> Would you please help review this trivial fix?
>
> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8204310
> WEBREV: http://cr.openjdk.java.net/~igerasim/8204310/00/webrev/
>
> All the existing tests pass Ok.
>
I think this should be okay but the Windows implementation has a long 
history of biting the fingers of anyone that dares touch it. Sometimes 
unexpected behavior changes only come to light long after the change. 
The recent mails here about Kafka and sparse files is a good example of 
that. So I think it's important to check the test coverage before 
pushing this change. Specifically I think we need to check that we have 
tests that

1. Exercise shrinking, extending, and not change the file length

2. Check getFilePointer when used with setLength.

3. Check how FileChannel behaves when created from a RandomAccessFile 
but the file length is changed after the FileChannel is obtained.

I realize this is more work than what you might have wanted to put into 
this but we have to extremely careful here.

-Alan



More information about the core-libs-dev mailing list