RFR [8055915]: (ch) FileDispatcherImpl.truncate0 should use SetFileInformationByHandle [win]

[Ivan Gerasimov]

Thank you Alan!

On 26.08.2014 0:15, Alan Bateman wrote:
> On 25/08/2014 15:37, Ivan Gerasimov wrote:
>> Hello!
>>
>> It is a proposal to reimplement FileDispatcherImpl.truncate0 with a
>> single call to SetFileInformationByHandle().
>> The later is available on Windows starting with Vista & Server 2008 [1].
>> The code should be buildable on XP & Server 2003.
>>
>> The existing test
>> java/nio/channels/AsynchronousFileChannel/Basic.java was used to
>> verify the functionality isn't broken.
>>
>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8055915
>> WEBREV: http://cr.openjdk.java.net/~igerasim/8055915/0/webrev/
 >
> I think this okay although I think I think a reminder about the size
> of LARGE_INTEGER to be confident that the conversion from jlong is
> correct.
>

According to MSDN [1], LARGE_INTEGER::QuadPart is a signed 64-bit 
integer, so it is compatible with jlong.

We already have a few places where QuadPart is assigned from jlong 
without any explicit casting.

On the other hand, the long_to_jlong macro is used in some places for 
the opposite conversion from QuadPart to jlong, but I don't really see 
why it was needed.

[1] 
http://msdn.microsoft.com/en-us/library/windows/desktop/aa383713(v=vs.85).aspx

> AsynchronousFileChannel/Basic.java just happens to exercise it so I
> won't update it's @bug.
>

Alright, I'll remove the test from the changeset.

> Best to run the :jdk_nio tests on Windows 32-bit and 64-bit to check
> the change.
>

I've done a control build on all the platforms and made JPRT run all 
jdk_nio tests - no single failure.


Sincerely yours,
Ivan