From brian.burkhalter at oracle.com  Thu Nov  2 00:55:02 2017
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Wed, 1 Nov 2017 17:55:02 -0700
Subject: RFR 8190500: (ch) ReadableByteChannelImpl::read and
 WritableByteChannelImpl::write might not throw ClosedChannelException as
 specified
Message-ID: <320670BE-157E-46D0-993C-BF9D505980C1@oracle.com>

https://bugs.openjdk.java.net/browse/JDK-8190500
http://cr.openjdk.java.net/~bpb/8190500/webrev.00/

Closing the channel returned by Channels::newChannel can result in a subsequent read/write's throwing an IOException instead of the expected ClosedChannelException in for a non-FileIn/OutputStream parameter.

Thanks,

Brian

From brian.burkhalter at oracle.com  Thu Nov  2 01:03:05 2017
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Wed, 1 Nov 2017 18:03:05 -0700
Subject: RFR 8190501: (fs) Incorrect error message parameter in
 java/nio/file/Files/probeContentType/Basic.java
Message-ID: <EAB9B433-EC48-4DBF-ACC7-A16821360CA6@oracle.com>

https://bugs.openjdk.java.net/browse/JDK-8190501

--- a/test/jdk/java/nio/file/Files/probeContentType/Basic.java
+++ b/test/jdk/java/nio/file/Files/probeContentType/Basic.java
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2008, 2016, Oracle and/or its affiliates. All rights reserved.
+ * Copyright (c) 2008, 2017, Oracle and/or its affiliates. All rights reserved.
  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
  *
  * This code is free software; you can redistribute it and/or modify it
@@ -114,7 +114,7 @@
                     failures++;
                 } else if (!type.equals(expectedTypes[i])) {
                     System.err.printf("Content type: %s; expected: %s%n",
-                        type, expectedTypes);
+                        type, expectedTypes[i]);
                     failures++;

The String[] expectedTypes is passed to a %s format instead of expectedTypes[i].

Thanks,

Brian

From brian.burkhalter at oracle.com  Thu Nov  2 01:07:04 2017
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Wed, 1 Nov 2017 18:07:04 -0700
Subject: RFR 8190502: (fs) Typo in java.nio.file.Files
Message-ID: <54A065A6-AB0D-41E2-8BF4-1ABAE8B52E21@oracle.com>

https://bugs.openjdk.java.net/browse/JDK-8190502

The word "subsequence" is used where "subsequent" was intended. 

--- a/src/java.base/share/classes/java/nio/file/Files.java
+++ b/src/java.base/share/classes/java/nio/file/Files.java
@@ -2401,7 +2401,7 @@
      *
      * <p> Note that the result of this method is immediately outdated. If this
      * method indicates the file exists then there is no guarantee that a
-     * subsequence access will succeed. Care should be taken when using this
+     * subsequent access will succeed. Care should be taken when using this
      * method in security sensitive applications.
@@ -2458,7 +2458,7 @@
      * or not then both methods return {@code false}. As with the {@code exists}
      * method, the result of this method is immediately outdated. If this
      * method indicates the file does exist then there is no guarantee that a
-     * subsequence attempt to create the file will succeed. Care should be taken
+     * subsequent attempt to create the file will succeed. Care should be taken
      * when using this method in security sensitive applications.

Thanks,

Brian

From Alan.Bateman at oracle.com  Thu Nov  2 08:10:03 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 2 Nov 2017 08:10:03 +0000
Subject: RFR 8190502: (fs) Typo in java.nio.file.Files
In-Reply-To: <54A065A6-AB0D-41E2-8BF4-1ABAE8B52E21@oracle.com>
References: <54A065A6-AB0D-41E2-8BF4-1ABAE8B52E21@oracle.com>
Message-ID: <755d9d9d-6caa-b57e-5385-acbc89cdb106@oracle.com>

+1

On 02/11/2017 01:07, Brian Burkhalter wrote:
> https://bugs.openjdk.java.net/browse/JDK-8190502
>
> The word "subsequence" is used where "subsequent" was intended.
>
> --- a/src/java.base/share/classes/java/nio/file/Files.java
> +++ b/src/java.base/share/classes/java/nio/file/Files.java
> @@ -2401,7 +2401,7 @@
>        *
>        * <p> Note that the result of this method is immediately outdated. If this
>        * method indicates the file exists then there is no guarantee that a
> -     * subsequence access will succeed. Care should be taken when using this
> +     * subsequent access will succeed. Care should be taken when using this
>        * method in security sensitive applications.
> @@ -2458,7 +2458,7 @@
>        * or not then both methods return {@code false}. As with the {@code exists}
>        * method, the result of this method is immediately outdated. If this
>        * method indicates the file does exist then there is no guarantee that a
> -     * subsequence attempt to create the file will succeed. Care should be taken
> +     * subsequent attempt to create the file will succeed. Care should be taken
>        * when using this method in security sensitive applications.
>
> Thanks,
>
> Brian


From Alan.Bateman at oracle.com  Thu Nov  2 08:10:29 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 2 Nov 2017 08:10:29 +0000
Subject: RFR 8190501: (fs) Incorrect error message parameter in
 java/nio/file/Files/probeContentType/Basic.java
In-Reply-To: <EAB9B433-EC48-4DBF-ACC7-A16821360CA6@oracle.com>
References: <EAB9B433-EC48-4DBF-ACC7-A16821360CA6@oracle.com>
Message-ID: <87d492c2-ce8a-530c-6f28-f10930b6a7b7@oracle.com>

+1

On 02/11/2017 01:03, Brian Burkhalter wrote:
> https://bugs.openjdk.java.net/browse/JDK-8190501
>
> --- a/test/jdk/java/nio/file/Files/probeContentType/Basic.java
> +++ b/test/jdk/java/nio/file/Files/probeContentType/Basic.java
> @@ -1,5 +1,5 @@
>   /*
> - * Copyright (c) 2008, 2016, Oracle and/or its affiliates. All rights reserved.
> + * Copyright (c) 2008, 2017, Oracle and/or its affiliates. All rights reserved.
>    * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>    *
>    * This code is free software; you can redistribute it and/or modify it
> @@ -114,7 +114,7 @@
>                       failures++;
>                   } else if (!type.equals(expectedTypes[i])) {
>                       System.err.printf("Content type: %s; expected: %s%n",
> -                        type, expectedTypes);
> +                        type, expectedTypes[i]);
>                       failures++;
>
> The String[] expectedTypes is passed to a %s format instead of expectedTypes[i].
>
> Thanks,
>
> Brian


From Alan.Bateman at oracle.com  Thu Nov  2 08:30:47 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 2 Nov 2017 08:30:47 +0000
Subject: RFR 8190500: (ch) ReadableByteChannelImpl::read and
 WritableByteChannelImpl::write might not throw ClosedChannelException as
 specified
In-Reply-To: <320670BE-157E-46D0-993C-BF9D505980C1@oracle.com>
References: <320670BE-157E-46D0-993C-BF9D505980C1@oracle.com>
Message-ID: <be869a94-0d83-bc86-a90a-76ca047b6720@oracle.com>

On 02/11/2017 00:55, Brian Burkhalter wrote:
> https://bugs.openjdk.java.net/browse/JDK-8190500
> http://cr.openjdk.java.net/~bpb/8190500/webrev.00/
>
> Closing the channel returned by Channels::newChannel can result in a subsequent read/write's throwing an IOException instead of the expected ClosedChannelException in for a non-FileIn/OutputStream parameter.
>
The change looks okay. Related is that someone with a reference to the 
underlying InputStream/OutpuStream could close the stream so that the 
channel read/write throw an IOException other than 
AsynchronousCloseException but that isn't something you can solve.

For the test then you might want to break up the really long lines to 
keep it consistent with the rest of the test.

-Alan

From brian.burkhalter at oracle.com  Thu Nov  2 15:54:21 2017
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Thu, 2 Nov 2017 08:54:21 -0700
Subject: RFR 8190500: (ch) ReadableByteChannelImpl::read and
 WritableByteChannelImpl::write might not throw ClosedChannelException as
 specified
In-Reply-To: <be869a94-0d83-bc86-a90a-76ca047b6720@oracle.com>
References: <320670BE-157E-46D0-993C-BF9D505980C1@oracle.com>
 <be869a94-0d83-bc86-a90a-76ca047b6720@oracle.com>
Message-ID: <EE141A35-3848-4158-852D-D259A59467FD@oracle.com>


On Nov 2, 2017, at 1:30 AM, Alan Bateman <Alan.Bateman at oracle.com> wrote:

> On 02/11/2017 00:55, Brian Burkhalter wrote:
>> https://bugs.openjdk.java.net/browse/JDK-8190500
>> http://cr.openjdk.java.net/~bpb/8190500/webrev.00/
>> 
>> Closing the channel returned by Channels::newChannel can result in a subsequent read/write's throwing an IOException instead of the expected ClosedChannelException in for a non-FileIn/OutputStream parameter.
>> 
> The change looks okay. Related is that someone with a reference to the underlying InputStream/OutpuStream could close the stream so that the channel read/write throw an IOException other than AsynchronousCloseException but that isn't something you can solve.

Yes, I thought of that also.

> For the test then you might want to break up the really long lines to keep it consistent with the rest of the test.

Done: webrev updated in place.

Thanks,

Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20171102/ba6642cf/attachment.html>

From Alan.Bateman at oracle.com  Thu Nov  2 16:36:27 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 2 Nov 2017 16:36:27 +0000
Subject: RFR 8190500: (ch) ReadableByteChannelImpl::read and
 WritableByteChannelImpl::write might not throw ClosedChannelException as
 specified
In-Reply-To: <EE141A35-3848-4158-852D-D259A59467FD@oracle.com>
References: <320670BE-157E-46D0-993C-BF9D505980C1@oracle.com>
 <be869a94-0d83-bc86-a90a-76ca047b6720@oracle.com>
 <EE141A35-3848-4158-852D-D259A59467FD@oracle.com>
Message-ID: <d6ba5a5f-7b4b-9093-549f-cad011176792@oracle.com>



On 02/11/2017 15:54, Brian Burkhalter wrote:
> :
>
> Done: webrev updated in place.
>
I don't wish to delay you on this but looking at it again then it might 
be better to put the tests for the closed channel into their own methods 
so that testNewChannelIn and testNewChannelOut test one thing each.

-Alan

From brian.burkhalter at oracle.com  Thu Nov  2 18:23:10 2017
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Thu, 2 Nov 2017 11:23:10 -0700
Subject: RFR 8190500: (ch) ReadableByteChannelImpl::read and
 WritableByteChannelImpl::write might not throw ClosedChannelException as
 specified
In-Reply-To: <d6ba5a5f-7b4b-9093-549f-cad011176792@oracle.com>
References: <320670BE-157E-46D0-993C-BF9D505980C1@oracle.com>
 <be869a94-0d83-bc86-a90a-76ca047b6720@oracle.com>
 <EE141A35-3848-4158-852D-D259A59467FD@oracle.com>
 <d6ba5a5f-7b4b-9093-549f-cad011176792@oracle.com>
Message-ID: <D7AA0931-9E6D-431D-9072-2A552CDE7CB4@oracle.com>


On Nov 2, 2017, at 9:36 AM, Alan Bateman <Alan.Bateman at oracle.com> wrote:

> I don't wish to delay you on this but looking at it again then it might be better to put the tests for the closed channel into their own methods so that testNewChannelIn and testNewChannelOut test one thing each.

No worries; I agree that is better. Here?s an updated version: http://cr.openjdk.java.net/~bpb/8190500/webrev.01/

Thanks,

Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20171102/4a6f19f6/attachment.html>

From Alan.Bateman at oracle.com  Fri Nov  3 12:04:23 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 3 Nov 2017 12:04:23 +0000
Subject: RFR 8190500: (ch) ReadableByteChannelImpl::read and
 WritableByteChannelImpl::write might not throw ClosedChannelException as
 specified
In-Reply-To: <D7AA0931-9E6D-431D-9072-2A552CDE7CB4@oracle.com>
References: <320670BE-157E-46D0-993C-BF9D505980C1@oracle.com>
 <be869a94-0d83-bc86-a90a-76ca047b6720@oracle.com>
 <EE141A35-3848-4158-852D-D259A59467FD@oracle.com>
 <d6ba5a5f-7b4b-9093-549f-cad011176792@oracle.com>
 <D7AA0931-9E6D-431D-9072-2A552CDE7CB4@oracle.com>
Message-ID: <100a546f-b1c1-eacb-801d-d63df9f0284b@oracle.com>



On 02/11/2017 18:23, Brian Burkhalter wrote:
>
> On Nov 2, 2017, at 9:36 AM, Alan Bateman <Alan.Bateman at oracle.com 
> <mailto:Alan.Bateman at oracle.com>> wrote:
>
>> I don't wish to delay you on this but looking at it again then it 
>> might be better to put the tests for the closed channel into their 
>> own methods so that testNewChannelIn and testNewChannelOut test one 
>> thing each.
>
> No worries; I agree that is better. Here?s an updated version: 
> http://cr.openjdk.java.net/~bpb/8190500/webrev.01/ 
> <http://cr.openjdk.java.net/%7Ebpb/8190500/webrev.01/>
>
It might be better to put the fos.close and fis.close into a finally 
block, or else else using try-with-resources in both methods. They 
aren't of course strictly needed but you've invited the question by 
allowing for the possibility that wbc/rbc.close doesn't close the 
underlying stream.

-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20171103/e74742c4/attachment.html>

From brian.burkhalter at oracle.com  Fri Nov  3 15:45:53 2017
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Fri, 3 Nov 2017 08:45:53 -0700
Subject: RFR 8190500: (ch) ReadableByteChannelImpl::read and
 WritableByteChannelImpl::write might not throw ClosedChannelException as
 specified
In-Reply-To: <100a546f-b1c1-eacb-801d-d63df9f0284b@oracle.com>
References: <320670BE-157E-46D0-993C-BF9D505980C1@oracle.com>
 <be869a94-0d83-bc86-a90a-76ca047b6720@oracle.com>
 <EE141A35-3848-4158-852D-D259A59467FD@oracle.com>
 <d6ba5a5f-7b4b-9093-549f-cad011176792@oracle.com>
 <D7AA0931-9E6D-431D-9072-2A552CDE7CB4@oracle.com>
 <100a546f-b1c1-eacb-801d-d63df9f0284b@oracle.com>
Message-ID: <7313A44D-DD91-4A79-A157-F185B5F8468D@oracle.com>


On Nov 3, 2017, at 5:04 AM, Alan Bateman <Alan.Bateman at oracle.com> wrote:

> It might be better to put the fos.close and fis.close into a finally block, or else else using try-with-resources in both methods. They aren't of course strictly needed but you've invited the question by allowing for the possibility that wbc/rbc.close doesn't close the underlying stream.

So updated. Please see http://cr.openjdk.java.net/~bpb/8190500/webrev.02/.

Thanks,

Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20171103/173e7a42/attachment.html>

From Alan.Bateman at oracle.com  Fri Nov  3 16:39:58 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 3 Nov 2017 16:39:58 +0000
Subject: RFR 8190500: (ch) ReadableByteChannelImpl::read and
 WritableByteChannelImpl::write might not throw ClosedChannelException as
 specified
In-Reply-To: <7313A44D-DD91-4A79-A157-F185B5F8468D@oracle.com>
References: <320670BE-157E-46D0-993C-BF9D505980C1@oracle.com>
 <be869a94-0d83-bc86-a90a-76ca047b6720@oracle.com>
 <EE141A35-3848-4158-852D-D259A59467FD@oracle.com>
 <d6ba5a5f-7b4b-9093-549f-cad011176792@oracle.com>
 <D7AA0931-9E6D-431D-9072-2A552CDE7CB4@oracle.com>
 <100a546f-b1c1-eacb-801d-d63df9f0284b@oracle.com>
 <7313A44D-DD91-4A79-A157-F185B5F8468D@oracle.com>
Message-ID: <3f6b9767-93ce-8260-cd66-807d0d059a5f@oracle.com>



On 03/11/2017 15:45, Brian Burkhalter wrote:
>
> On Nov 3, 2017, at 5:04 AM, Alan Bateman <Alan.Bateman at oracle.com 
> <mailto:Alan.Bateman at oracle.com>> wrote:
>
>> It might be better to put the fos.close and fis.close into a finally 
>> block, or else else using try-with-resources in both methods. They 
>> aren't of course strictly needed but you've invited the question by 
>> allowing for the possibility that wbc/rbc.close doesn't close the 
>> underlying stream.
>
> So updated. Please see 
> http://cr.openjdk.java.net/~bpb/8190500/webrev.02/ 
> <http://cr.openjdk.java.net/%7Ebpb/8190500/webrev.02/>.
>
Looks fine.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20171103/349ff2c5/attachment.html>

From fridrich.strba at suse.com  Thu Nov  9 08:38:46 2017
From: fridrich.strba at suse.com (Fridrich Strba)
Date: Thu, 9 Nov 2017 09:38:46 +0100
Subject: A possible fix for JDK-8165852: Mount point not found for a file
 which is present in overlayfs
In-Reply-To: <C0EA6110-F870-4863-B966-291E49A18271@oracle.com>
References: <acc740c7-7ea2-39a5-7c5e-2f7b4160df86@suse.com>
 <C0EA6110-F870-4863-B966-291E49A18271@oracle.com>
Message-ID: <033449ae-83e8-04ad-5e8e-932ebc88b3df@suse.com>

Ping

On 27/09/17 16:50, Brian Burkhalter wrote:
> Hello, Fridrich,
> 
> Excellent! This would be good if it works albeit inelegantly: function over form. I?ll add it to my list to review. To test it I will need to dust off my Linux VM which has all this stuff (Docker, btrfs, etc.) installed.
> 
> Thanks,
> 
> Brian
> 
> On Sep 27, 2017, at 5:31 AM, Fridrich Strba <fridrich.strba at suse.com> wrote:
> 
>> Hello, good people,
>>
>> I think I fixed the overlayfs and btrfs problems in LinuxFileStore. The
>> attached patch is what makes it work for us. Basically, when we come to
>> the device-id boundary, we check whether it corresponds to a mount point
>> in the files and if so, we return. If not, we go down the file system
>> looking for another boundary. If we come to the root of the file-system
>> without finding other mount-point and if the / is in the files, we
>> return the entry that corresponds to it. If not, we throw the exception.
>>
>> It is not elegant, but it works. I would love to have someone to look at
>> it and consider whether it could be up-streamed.
>>
>> Thanks in advance
>>
>> Fridrich
>>
>>
>> <java-10-openjdk-linuxfilestore.patch>
> 
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL: <http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20171109/3e0b5e97/signature.asc>

From brian.burkhalter at oracle.com  Thu Nov  9 19:54:08 2017
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Thu, 9 Nov 2017 11:54:08 -0800
Subject: RFR 8191025: (ch) Scattering reads to a subsequence of buffers
 ignores length
Message-ID: <EC15784A-C280-4738-9DE1-EBEDCDC3FC6D@oracle.com>

https://bugs.openjdk.java.net/browse/JDK-8191025
http://cr.openjdk.java.net/~bpb/8191025/webrev.00/

bufs.length was inadvertently passed instead of length resulting in a NPE when length < bufs.length and bufs[idx] == null for some idx in [length,bufs.length).

Thanks,

Brian

From Roger.Riggs at Oracle.com  Thu Nov  9 21:14:14 2017
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Thu, 9 Nov 2017 16:14:14 -0500
Subject: RFR 8191025: (ch) Scattering reads to a subsequence of buffers
 ignores length
In-Reply-To: <EC15784A-C280-4738-9DE1-EBEDCDC3FC6D@oracle.com>
References: <EC15784A-C280-4738-9DE1-EBEDCDC3FC6D@oracle.com>
Message-ID: <c694dbce-0fd9-a37a-d544-4eaa96579547@Oracle.com>

Hi Brian,

That looks good.

Roger


On 11/9/2017 2:54 PM, Brian Burkhalter wrote:
> https://bugs.openjdk.java.net/browse/JDK-8191025
> http://cr.openjdk.java.net/~bpb/8191025/webrev.00/
>
> bufs.length was inadvertently passed instead of length resulting in a NPE when length < bufs.length and bufs[idx] == null for some idx in [length,bufs.length).
>
> Thanks,
>
> Brian


From Alan.Bateman at oracle.com  Thu Nov  9 21:18:50 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 9 Nov 2017 22:18:50 +0100
Subject: RFR 8191025: (ch) Scattering reads to a subsequence of buffers
 ignores length
In-Reply-To: <EC15784A-C280-4738-9DE1-EBEDCDC3FC6D@oracle.com>
References: <EC15784A-C280-4738-9DE1-EBEDCDC3FC6D@oracle.com>
Message-ID: <6ced4705-a082-b705-6e04-800b3e2ff92f@oracle.com>

On 09/11/2017 20:54, Brian Burkhalter wrote:
> https://bugs.openjdk.java.net/browse/JDK-8191025
> http://cr.openjdk.java.net/~bpb/8191025/webrev.00/
>
> bufs.length was inadvertently passed instead of length resulting in a NPE when length < bufs.length and bufs[idx] == null for some idx in [length,bufs.length).
>
Looks good, just surprised it wasn't caught by other tests.

-Alan

From brian.burkhalter at oracle.com  Thu Nov  9 21:25:37 2017
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Thu, 9 Nov 2017 13:25:37 -0800
Subject: RFR 8191025: (ch) Scattering reads to a subsequence of buffers
 ignores length
In-Reply-To: <6ced4705-a082-b705-6e04-800b3e2ff92f@oracle.com>
References: <EC15784A-C280-4738-9DE1-EBEDCDC3FC6D@oracle.com>
 <6ced4705-a082-b705-6e04-800b3e2ff92f@oracle.com>
Message-ID: <6C6AC31E-7C3E-4B44-903A-7C3558A0298E@oracle.com>

On Nov 9, 2017, at 1:18 PM, Alan Bateman <Alan.Bateman at oracle.com> wrote:

> Looks good, just surprised it wasn't caught by other tests.

Same here. Seems like a hole that was already there in the pre-direct I/O tests. Note that the test change also defensively covers the analogous write case which does not currently have the same problem.

Thanks,

Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20171109/8721e96b/attachment.html>