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