RFR 8204310 : Simpler RandomAccessFile.setLength() on Windows

Bernd Eckenfels ecki at zusammenkunft.net
Mon Jun 11 07:55:50 UTC 2018




	
		
		
	
		We had BTW problems (on Windows) with SMB hosted files where appending causes sometimes the filepointer to not increase. We fixed that by closing the file in such conditions. It does however look like a smb Cache and not Java Code problem. But just in case anyone has seen encountered that...
Not sure how easy it is to replicate, but will let you know.
Bernd
		-- https://Bernd.eckenfels.net
	





On Mon, Jun 11, 2018 at 9:45 AM +0200, "Ivan Gerasimov" <ivan.gerasimov at oracle.com> wrote:










Hi Alan!


On 6/6/18 6:57 AM, Alan Bateman wrote:
> 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 extended the existing reg. test 
java/io/RandomAccessFile/SetLength.java to cover more cases that involve 
changing the file size.

Also I added another regression test, as you Alan suggested, to check 
that RandomAccessFile and its FileChannel behave consistently in various 
scenarios.

All the tests, including the new ones, pass on all supported platforms.

BUGURL: https://bugs.openjdk.java.net/browse/JDK-8204310
WEBREV: http://cr.openjdk.java.net/~igerasim/8204310/01/webrev/

Would you please help review the fix?

-- 
With kind regards,
Ivan Gerasimov








More information about the core-libs-dev mailing list