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
