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.gerasi...@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
