From Alan.Bateman at oracle.com Fri Mar 1 10:06:45 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 1 Mar 2019 10:06:45 +0000 Subject: 8219876: (bf) Improve IndexOutOfBoundsException messages in $Type$Buffer classes In-Reply-To: <6C0D81F3-A217-4C59-A9EB-B3EE1F70F9D3@oracle.com> References: <6C0D81F3-A217-4C59-A9EB-B3EE1F70F9D3@oracle.com> Message-ID: <03e092da-4abe-0e90-d664-044dba455cf6@oracle.com> On 28/02/2019 21:57, Brian Burkhalter wrote: > >> On Feb 27, 2019, at 11:57 PM, Alan Bateman > > wrote: >> >> I assume you'll run benchmarks and/or look at the generated code to >> make sure that the checks inline as expected. > > The benchmark output [1] shows a small improvement for a 1024-byte > bulk get and a slight degradation for a 1-byte bulk get. The benchmark > code is [2]. > > The disassembled classes [3] (from ?javap -c?) differ in the presence > of a ?pop? for the new code containing Objects.checkFromIndexSize(). > I should have been clearer, I meant the code generated at runtime, as in -XX:+PrintAssembly but if you are doing benchmarks to make sure the changes don't regress then it should be good. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Fri Mar 1 10:25:07 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 1 Mar 2019 10:25:07 +0000 Subject: 8219597: (bf) Heap buffer state changes could provoke unexpected exceptions In-Reply-To: <506BB04A-BA38-4FC3-B131-DA23F6EC103B@oracle.com> References: <506BB04A-BA38-4FC3-B131-DA23F6EC103B@oracle.com> Message-ID: <151449be-abd1-fe22-d2ad-94854451dc6f@oracle.com> On 27/02/2019 19:36, Brian Burkhalter wrote: > This issue [1] was instigated by this comment [2]. The change [3] hopefully reduces the exposure of heap buffers to changes in the buffer state, notably the position (cursor). > I saw Roger's mail but I think these changes just mean the position/limit checked in the preconditions are the values used.? So I think the changes are okay. One more to look at is the checkIndex usages in the new 2-arg slice method.? A minor nit at L242 where the line break makes it harder to read. -Alan From christoph.langer at sap.com Fri Mar 1 10:34:38 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 1 Mar 2019 10:34:38 +0000 Subject: RFR 8213031: (zipfs) Add support for POSIX file permissions In-Reply-To: <9b3c9cfe-63e9-94ea-1af0-7ba9e2db52fd@oracle.com> References: <7b513a34196141f595cd5d194fb9d8a2@sap.com> <46af4f9d-60f9-c60d-e6f1-8fb97df3ba2e@oracle.com> <5d28b0715d2041ff892a3c44e024f120@sap.com> <8e9231ff-b7d5-bc2f-2643-713f3c670a1d@oracle.com> <3aeba9a64a434a968fc1d82a44077745@sap.com> <953449f0913340f6a94ae3d83611fd92@sap.com> <9b3c9cfe-63e9-94ea-1af0-7ba9e2db52fd@oracle.com> Message-ID: <88a4a568362a42858671678271295195@sap.com> Hi Alan, thanks for diving into this and giving a comprehensive summary. I've just read it in detail now - and as always, it contains some very good findings and suggestions. I'll try to work these in and send an update in the next days. Best regards Christoph > -----Original Message----- > From: Alan Bateman > Sent: Montag, 25. Februar 2019 09:31 > To: Langer, Christoph > Cc: nio-dev ; Java Core Libs dev at openjdk.java.net> > Subject: Re: RFR 8213031: (zipfs) Add support for POSIX file permissions > > On 21/02/2019 15:04, Langer, Christoph wrote: > > Hi Alan, > > > > here is the next > iteration:http://cr.openjdk.java.net/~clanger/webrevs/8213031.7/ > > > > I focused on your comments regarding implementation details: > > > > : > > Are there other major implementation points left? If not I guess we should > start refining the documentation... > > I think it would be useful to write down a summary of the proposal as > there are several detailed points that we've been discussing in this > thread that reviewers will need to understand the proposal before diving > into the implementation/patch.? This might also help getting the javadoc > aligned, and eventually the CSR. Here's where I think we are: > > 1. By default, a zip file system will have no support for the "posix" > and "owner" views of file attributes, this means the following will fail > with UOE: > > ? PosixFileAttributes attrs = Files.readAttributes(file, > PosixFileAttributes.class); > > and the zip file system's supportedFileAttributView method will not > include "posix". > > 2. Creating a zip file system with configuration parameter XXX set to > "true" will create the zip file system that supports > PosixFileAttributeView (and FileOwnerAttributeView). The current patch > names the configuration parameter "posix". That name might be misleading > as a configuration parameter as it conveys more than it actually does. > Something like "enablePosixFileAttributes" clear conveys that it enables > support for POSIX file attribute but might be a better wordy. > > The value in the configuration map is documented as Boolean but I think > we are allowing it to be the string representation of a Boolean, meaning > it can be "true" or "false" like we have with the "create" parameter. > > 3. The map of configurations parameters can optionally include the > parameters "defaultOwner", "defaultGroup", and "defaultPermissions" with > the default owner/group/permissions to return. These names seem okay to > me. > > For the owner/group, the parameter type can be > UserPrincipal/GroupPrincipal or strings. If the value is a String then > we need to decide if there is any validation. If I read the current > patch correctly then it doesn't do any validation - that might be okay > but minimally maybe we should disallow the empty string. > > If the defaultXXX parameters aren't present then the zip file > owner/group would be a sensible default. If the zip file is on a file > store that supports FileOwnerAttributeView then we've got the owner. If > the file store supports PosixFileAttributeView then we have a group > owner. If PosixFileAttributeView is not supported then using the owner > as the group is okay. I see the current patch as a fallback to fallback > to "" but I'd prefer not have that because it will be > very confusing to diagnose if there are issues. > > For defaultPermissions, the value is a Set or the > string representation. In the implementation, initPermissions can be > changed to use PosixFilePermissions.fromString as it does the > translation that we need. > > 4. As an alternative to the type safe access that PosixFileAttributeView > provides, the proposal is to document the "zip" view of file attributes. > Initially, it will admit to one file attribute for the permissions. The > current patch uses the name "storedPermissions" but it might be simpler > to use "permissions" so that "zip:permissions" and "posix:permissions" > are the same when the zip entry has permissions. With this support you > can write code like this: > ??? Set perms = (Set) > Files.getAttribute(file, "zip:permissions"); > > The cast is ugly of course but that's the consequence of not exposing > ZipFileAttributes in the API so there is no type token to specify on the > RHS. > > Documenting the "zip" view brings up a few issues, e.g. will > Files.readAttributes(file, "zip:*") reveal more than "permissions". For > this API it is okay for the map to attributes beyond the specified list. > > 5. There will be no support for specifying as POSIX FileAttribute to > createFile or createDirectory to atomically set the permissions when > creating a new file/directory, UOE will thrown as is is now. > > Is this a reasonable summary? > > -Alan From brian.burkhalter at oracle.com Fri Mar 1 17:28:38 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 1 Mar 2019 09:28:38 -0800 Subject: 8219597: (bf) Heap buffer state changes could provoke unexpected exceptions In-Reply-To: <151449be-abd1-fe22-d2ad-94854451dc6f@oracle.com> References: <506BB04A-BA38-4FC3-B131-DA23F6EC103B@oracle.com> <151449be-abd1-fe22-d2ad-94854451dc6f@oracle.com> Message-ID: <1A85762C-8B8D-4893-88E6-365E02DDFAFF@oracle.com> > On Mar 1, 2019, at 2:25 AM, Alan Bateman wrote: > > On 27/02/2019 19:36, Brian Burkhalter wrote: >> This issue [1] was instigated by this comment [2]. The change [3] hopefully reduces the exposure of heap buffers to changes in the buffer state, notably the position (cursor). >> > I saw Roger's mail but I think these changes just mean the position/limit checked in the preconditions are the values used. So I think the changes are okay. One more to look at is the checkIndex usages in the new 2-arg slice method. Yes I think that this 117 public $Type$Buffer slice(int index, int length) { 118 Objects.checkIndex(index, limit() + 1); 119 Objects.checkIndex(length, limit() - index + 1); should be changed to 117 public $Type$Buffer slice(int index, int length) { 118 Objects.checkFromIndexSize(index, length, limit() + 1); and also in the other places slice(int,int) occurs. IIRC I had it that way to begin with and modified it while addressing comments. I think however that this change perhaps ought to be the subject of a separate issue. > A minor nit at L242 where the line break makes it harder to read. I can change that before checking in. Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Tue Mar 5 09:08:49 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 5 Mar 2019 09:08:49 +0000 Subject: 8219597: (bf) Heap buffer state changes could provoke unexpected exceptions In-Reply-To: <1A85762C-8B8D-4893-88E6-365E02DDFAFF@oracle.com> References: <506BB04A-BA38-4FC3-B131-DA23F6EC103B@oracle.com> <151449be-abd1-fe22-d2ad-94854451dc6f@oracle.com> <1A85762C-8B8D-4893-88E6-365E02DDFAFF@oracle.com> Message-ID: <50BF24BE-E32F-492D-9641-0D384E9078C4@oracle.com> > On Mar 1, 2019, at 5:28 PM, Brian Burkhalter wrote: > >> So I think the changes are okay. One more to look at is the checkIndex usages in the new 2-arg slice method. > > Yes I think that this > 117 public $Type$Buffer slice(int index, int length) { > 118 Objects.checkIndex(index, limit() + 1); > 119 Objects.checkIndex(length, limit() - index + 1); > should be changed to > 117 public $Type$Buffer slice(int index, int length) { > 118 Objects.checkFromIndexSize(index, length, limit() + 1); > and also in the other places slice(int,int) occurs. IIRC I had it that way to begin with and modified it while addressing comments. I think however that this change perhaps ought to be the subject of a separate issue. I think I can check this in and file a separate issue to address the above. >> A minor nit at L242 where the line break makes it harder to read. > > I can change that before checking in. On reexamination I don?t see what you mean at L242. Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From goetz.lindenmaier at sap.com Fri Mar 8 14:24:52 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 8 Mar 2019 14:24:52 +0000 Subject: java/nio/file/Files/CopyAndMove.java is failing Message-ID: Hi, could I get some help with this failure? We are setting java.io.tempdir in our jtreg runs. With this setting, the test fails on windows. It reproduces easily on any call to jtreg. boolean sameDevice = getFileStore(dir1).equals(getFileStore(dir2)); returns false, although the directories are on the same disk etc. Later, the test succeeds moving the file. See also what I posted to https://bugs.openjdk.java.net/browse/JDK-8219644 8219644: java/nio/file/Files/CopyAndMove.java: Test threw exception: java.lang.RuntimeException: AtomicMoveNotSupportedException expected Best regards, Goetz. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Roger.Riggs at oracle.com Mon Mar 11 15:52:26 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Mon, 11 Mar 2019 11:52:26 -0400 Subject: java/nio/file/Files/CopyAndMove.java is failing In-Reply-To: References: Message-ID: <53575ce8-33e8-a15e-fede-8b239e37d4a3@oracle.com> Hi, I notice that WindowsFileStore.equals does a case sensitive comparison on the root name and the output in the bug shows that the drive letter has different case. You could see if the test works with capital "C:". Regards, Roger On 03/08/2019 09:24 AM, Lindenmaier, Goetz wrote: > > Hi, > > could I get some help with this failure? > > We are setting java.io.tempdir in our jtreg runs. > > With this setting, the test fails on windows. > > It reproduces easily on any call to jtreg. > > boolean sameDevice = getFileStore(dir1).equals(getFileStore(dir2)); > > returns false, although the directories are on the same disk etc. > > Later, the test succeeds moving the file. > > See also what I posted to > > https://bugs.openjdk.java.net/browse/JDK-8219644 > > 8219644: java/nio/file/Files/CopyAndMove.java: Test threw exception: > java.lang.RuntimeException: AtomicMoveNotSupportedException expected > > Best regards, > > ? Goetz. > From goetz.lindenmaier at sap.com Tue Mar 12 08:21:52 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 12 Mar 2019 08:21:52 +0000 Subject: java/nio/file/Files/CopyAndMove.java is failing In-Reply-To: <53575ce8-33e8-a15e-fede-8b239e37d4a3@oracle.com> References: <53575ce8-33e8-a15e-fede-8b239e37d4a3@oracle.com> Message-ID: Hi Roger, yes, it works with a capital 'C'. Should the constructor do this.root = root.toLowerCase()? Or should the equals method do root.toLowerCase().equals(other.root.toLowerCase())? Best regards, Goetz. > -----Original Message----- > From: nio-dev On Behalf Of Roger Riggs > Sent: Montag, 11. M?rz 2019 16:52 > To: nio-dev at openjdk.java.net > Subject: Re: java/nio/file/Files/CopyAndMove.java is failing > > Hi, > > I notice that WindowsFileStore.equals does a case sensitive > comparison on the root name and the output in the bug shows that > the drive letter has different case. > You could see if the test works with capital "C:". > > Regards, Roger > > > On 03/08/2019 09:24 AM, Lindenmaier, Goetz wrote: > > > > Hi, > > > > could I get some help with this failure? > > > > We are setting java.io.tempdir in our jtreg runs. > > > > With this setting, the test fails on windows. > > > > It reproduces easily on any call to jtreg. > > > > boolean sameDevice = getFileStore(dir1).equals(getFileStore(dir2)); > > > > returns false, although the directories are on the same disk etc. > > > > Later, the test succeeds moving the file. > > > > See also what I posted to > > > > https://bugs.openjdk.java.net/browse/JDK-8219644 > > > > 8219644: java/nio/file/Files/CopyAndMove.java: Test threw exception: > > java.lang.RuntimeException: AtomicMoveNotSupportedException expected > > > > Best regards, > > > > ? Goetz. > > From Alan.Bateman at oracle.com Tue Mar 12 08:28:22 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 12 Mar 2019 08:28:22 +0000 Subject: java/nio/file/Files/CopyAndMove.java is failing In-Reply-To: References: <53575ce8-33e8-a15e-fede-8b239e37d4a3@oracle.com> Message-ID: <2a1e4185-9e00-9cd9-a916-302cecd3635b@oracle.com> On 12/03/2019 08:21, Lindenmaier, Goetz wrote: > Hi Roger, > > yes, it works with a capital 'C'. > > Should the constructor do > this.root = root.toLowerCase()? > > Or should the equals method do > root.toLowerCase().equals(other.root.toLowerCase())? Well spotted by Roger, it seems we have a long standing bug here. As regards fixing this when we can re-purpose the existing bug or create a new one. toLowerCase is locale sensitive, it's more likely that it should be equalsIgnoreCase but I think needs a bit of study to ensure that this is correct for cases such as when the root directory is a UNC server. -Alan From goetz.lindenmaier at sap.com Tue Mar 12 08:43:07 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 12 Mar 2019 08:43:07 +0000 Subject: java/nio/file/Files/CopyAndMove.java is failing In-Reply-To: <2a1e4185-9e00-9cd9-a916-302cecd3635b@oracle.com> References: <53575ce8-33e8-a15e-fede-8b239e37d4a3@oracle.com> <2a1e4185-9e00-9cd9-a916-302cecd3635b@oracle.com> Message-ID: Hi Alan, feel free to re-purpose the bug. I'll add some information about the cause of the failure to it. Tell me where I can further help with this issue. Best regards, Goetz. > -----Original Message----- > From: Alan Bateman > Sent: Dienstag, 12. M?rz 2019 09:28 > To: Lindenmaier, Goetz ; Roger Riggs > ; nio-dev at openjdk.java.net > Subject: Re: java/nio/file/Files/CopyAndMove.java is failing > > On 12/03/2019 08:21, Lindenmaier, Goetz wrote: > > Hi Roger, > > > > yes, it works with a capital 'C'. > > > > Should the constructor do > > this.root = root.toLowerCase()? > > > > Or should the equals method do > > root.toLowerCase().equals(other.root.toLowerCase())? > Well spotted by Roger, it seems we have a long standing bug here. As > regards fixing this when we can re-purpose the existing bug or create a > new one. toLowerCase is locale sensitive, it's more likely that it > should be equalsIgnoreCase but I think needs a bit of study to ensure > that this is correct for cases such as when the root directory is a UNC > server. > > -Alan From ecki at zusammenkunft.net Tue Mar 12 09:38:51 2019 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Tue, 12 Mar 2019 09:38:51 +0000 Subject: java/nio/file/Files/CopyAndMove.java is failing In-Reply-To: <2a1e4185-9e00-9cd9-a916-302cecd3635b@oracle.com> References: <53575ce8-33e8-a15e-fede-8b239e37d4a3@oracle.com> , <2a1e4185-9e00-9cd9-a916-302cecd3635b@oracle.com> Message-ID: Hello, Note also that there is a NTFS flag which makes it case sensitive. And this is since 1804 even on a per folder base. What?s worse is that the flag is per default set for Linux for Windows Files. And also the posix Flag for CreateFile enables this (which needs to be observed if you want to use it for delete) Maybe it would be better to keep compare case sensitive (if you do not want to implement fe specific config) and instead make sure the reported roots are canonicalized from the filesystem? Gruss Bernd -- http://bernd.eckenfels.net ________________________________ Von: nio-dev im Auftrag von Alan Bateman Gesendet: Dienstag, M?rz 12, 2019 10:28 AM An: Lindenmaier, Goetz; Roger Riggs; nio-dev at openjdk.java.net Betreff: Re: java/nio/file/Files/CopyAndMove.java is failing On 12/03/2019 08:21, Lindenmaier, Goetz wrote: > Hi Roger, > > yes, it works with a capital 'C'. > > Should the constructor do > this.root = root.toLowerCase()? > > Or should the equals method do > root.toLowerCase().equals(other.root.toLowerCase())? Well spotted by Roger, it seems we have a long standing bug here. As regards fixing this when we can re-purpose the existing bug or create a new one. toLowerCase is locale sensitive, it's more likely that it should be equalsIgnoreCase but I think needs a bit of study to ensure that this is correct for cases such as when the root directory is a UNC server. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Thu Mar 14 00:19:22 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 13 Mar 2019 17:19:22 -0700 Subject: 8220614: (bf) Buffer absolute slice methods should use Objects.checkFromIndexSize() Message-ID: <8FA0AE66-19FD-42BD-A253-DD2041C452EC@oracle.com> Please review this simple change to improve parameter bounds checks in the recently added absolute slice methods. Thanks, Brian https://bugs.openjdk.java.net/browse/JDK-8220614 http://cr.openjdk.java.net/~bpb/8220614/webrev.00/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivan.gerasimov at oracle.com Thu Mar 14 00:42:35 2019 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Wed, 13 Mar 2019 17:42:35 -0700 Subject: 8220614: (bf) Buffer absolute slice methods should use Objects.checkFromIndexSize() In-Reply-To: <8FA0AE66-19FD-42BD-A253-DD2041C452EC@oracle.com> References: <8FA0AE66-19FD-42BD-A253-DD2041C452EC@oracle.com> Message-ID: <782675cf-b016-9dd8-cef3-35cc4bfbf50c@oracle.com> Hi Brian! While you're there. It seems that the check at StringCharBuffer, lines 39-41 can also be simplified as Object.checkFromToIndex?(start, end, s.length()); A few other places (toString, subSequence) in some Buffers could also benefit from this kind of refactoring. Or save it for a separate cleanup :) With kind regards, Ivan On 3/13/19 5:19 PM, Brian Burkhalter wrote: > Please review this simple change to improve parameter bounds checks in > the recently added absolute slice methods. > > Thanks, > > Brian > > https://bugs.openjdk.java.net/browse/JDK-8220614 > http://cr.openjdk.java.net/~bpb/8220614/webrev.00/ > -- With kind regards, Ivan Gerasimov -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Thu Mar 14 14:26:38 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 14 Mar 2019 07:26:38 -0700 Subject: 8220614: (bf) Buffer absolute slice methods should use Objects.checkFromIndexSize() In-Reply-To: <782675cf-b016-9dd8-cef3-35cc4bfbf50c@oracle.com> References: <8FA0AE66-19FD-42BD-A253-DD2041C452EC@oracle.com> <782675cf-b016-9dd8-cef3-35cc4bfbf50c@oracle.com> Message-ID: <7BFE2384-D1B6-4B07-8B0A-49AA0C316919@oracle.com> Hi Ivan, > On Mar 13, 2019, at 5:42 PM, Ivan Gerasimov wrote: > > While you're there. > > It seems that the check at StringCharBuffer, lines 39-41 can also be simplified as > Object.checkFromToIndex?(start, end, s.length()); > > A few other places (toString, subSequence) in some Buffers could also benefit from this kind of refactoring. All good points. Thanks for catching them. > Or save it for a separate cleanup :) I think it would be better to file a separate issue to deal with these. Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From Roger.Riggs at oracle.com Thu Mar 14 14:40:45 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Thu, 14 Mar 2019 10:40:45 -0400 Subject: 8220614: (bf) Buffer absolute slice methods should use Objects.checkFromIndexSize() In-Reply-To: <8FA0AE66-19FD-42BD-A253-DD2041C452EC@oracle.com> References: <8FA0AE66-19FD-42BD-A253-DD2041C452EC@oracle.com> Message-ID: <66ac6cd7-b78c-7b33-824c-385e38b6eb59@oracle.com> Looks fine Brian.? +1 On 03/13/2019 08:19 PM, Brian Burkhalter wrote: > Please review this simple change to improve parameter bounds checks in > the recently added absolute slice methods. > > Thanks, > > Brian > > https://bugs.openjdk.java.net/browse/JDK-8220614 > http://cr.openjdk.java.net/~bpb/8220614/webrev.00/ > From Alan.Bateman at oracle.com Thu Mar 14 14:56:54 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 14 Mar 2019 14:56:54 +0000 Subject: 8220614: (bf) Buffer absolute slice methods should use Objects.checkFromIndexSize() In-Reply-To: <8FA0AE66-19FD-42BD-A253-DD2041C452EC@oracle.com> References: <8FA0AE66-19FD-42BD-A253-DD2041C452EC@oracle.com> Message-ID: On 14/03/2019 00:19, Brian Burkhalter wrote: > Please review this simple change to improve parameter bounds checks in > the recently added absolute slice methods. Looks good. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Thu Mar 14 23:06:05 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 14 Mar 2019 16:06:05 -0700 Subject: 8219876: (bf) Improve IndexOutOfBoundsException messages in $Type$Buffer classes In-Reply-To: <03e092da-4abe-0e90-d664-044dba455cf6@oracle.com> References: <6C0D81F3-A217-4C59-A9EB-B3EE1F70F9D3@oracle.com> <03e092da-4abe-0e90-d664-044dba455cf6@oracle.com> Message-ID: <00BA5DE6-C8BD-4B75-AA2E-E9CDB83E968D@oracle.com> > On Mar 1, 2019, at 2:06 AM, Alan Bateman wrote: > > On 28/02/2019 21:57, Brian Burkhalter wrote: >> >>> On Feb 27, 2019, at 11:57 PM, Alan Bateman > wrote: >>> >>> I assume you'll run benchmarks and/or look at the generated code to make sure that the checks inline as expected. >> >> >> The benchmark output [1] shows a small improvement for a 1024-byte bulk get and a slight degradation for a 1-byte bulk get. The benchmark code is [2]. >> >> The disassembled classes [3] (from ?javap -c?) differ in the presence of a ?pop? for the new code containing Objects.checkFromIndexSize(). >> > I should have been clearer, I meant the code generated at runtime, as in -XX:+PrintAssembly but if you are doing benchmarks to make sure the changes don't regress then it should be good. I have to say that the generated code as in -XX:+PrintAssembly remains inscrutable to me, but I re-ran the benchmark with before and after release builds on a more or less quiescent system and the proposed change actually shows a small performance improvement for both 1- and 1024-byte bulk gets [1]. While we are at it, modifying the original patch [2] as suggested in [3] might be worthwhile. The delta is at [4] with the composite patch at [5]. Thanks, Brian [1] Benchmark output [1A] Before Benchmark Mode Cnt Score Error Units CheckBounds.bulkGet1 thrpt 10 168709599.809 ? 18518204.156 ops/s CheckBounds.bulkGet1024 thrpt 10 31044391.178 ? 402021.088 ops/s [1B] After Benchmark Mode Cnt Score Error Units CheckBounds.bulkGet1 thrpt 10 175271277.362 ? 2458135.860 ops/s CheckBounds.bulkGet1024 thrpt 10 32265609.310 ? 400376.804 ops/s [2] http://cr.openjdk.java.net/~bpb/8219876/webrev.00/ [3] http://mail.openjdk.java.net/pipermail/nio-dev/2019-March/005954.html [4] http://cr.openjdk.java.net/~bpb/8219876/webrev.00-01/ [5] http://cr.openjdk.java.net/~bpb/8219876/webrev.01/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From Roger.Riggs at oracle.com Fri Mar 15 19:22:59 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Fri, 15 Mar 2019 15:22:59 -0400 Subject: 8219876: (bf) Improve IndexOutOfBoundsException messages in $Type$Buffer classes In-Reply-To: <00BA5DE6-C8BD-4B75-AA2E-E9CDB83E968D@oracle.com> References: <6C0D81F3-A217-4C59-A9EB-B3EE1F70F9D3@oracle.com> <03e092da-4abe-0e90-d664-044dba455cf6@oracle.com> <00BA5DE6-C8BD-4B75-AA2E-E9CDB83E968D@oracle.com> Message-ID: Hi Brian, The latest patch [5] looks fine. Roger On 03/14/2019 07:06 PM, Brian Burkhalter wrote: > >> On Mar 1, 2019, at 2:06 AM, Alan Bateman > > wrote: >> >> On 28/02/2019 21:57, Brian Burkhalter wrote: >>> >>>> On Feb 27, 2019, at 11:57 PM, Alan Bateman >>> > wrote: >>>> >>>> I assume you'll run benchmarks and/or look at the generated code to >>>> make sure that the checks inline as expected. >>> >>> The benchmark output [1] shows a small improvement for a 1024-byte >>> bulk get and a slight degradation for a 1-byte bulk get. The >>> benchmark code is [2]. >>> >>> The disassembled classes [3] (from ?javap -c?) differ in the >>> presence of a ?pop? for the new code containing >>> Objects.checkFromIndexSize(). >>> >> I should have been clearer, I meant the code generated at runtime, as >> in -XX:+PrintAssembly but if you are doing benchmarks to make sure >> the changes don't regress then it should be good. > > I have to say that the generated code as in -XX:+PrintAssembly remains > inscrutable to me, but I re-ran the benchmark with before and after > release builds on a more or less quiescent system and the proposed > change actually shows a small performance improvement for both 1- and > 1024-byte bulk gets [1]. > > While we are at it, modifying the original patch [2] as suggested in > [3] might be worthwhile. The delta is at [4] with the composite patch > at [5]. > > Thanks, > > Brian > > [1] Benchmark output > [1A] Before > > Benchmark ? ? ? ? ? ? ? ? Mode? Cnt Score? ? ? ? ? Error? Units > CheckBounds.bulkGet1 ? ? thrpt ? 10 168709599.809 ? 18518204.156? ops/s > CheckBounds.bulkGet1024? thrpt ? 10 31044391.178 ? ? 402021.088? ops/s > > [1B] After > > Benchmark ? ? ? ? ? ? ? ? Mode? Cnt Score ? ? ? ? Error? Units > CheckBounds.bulkGet1 ? ? thrpt ? 10 175271277.362 ? 2458135.860? ops/s > CheckBounds.bulkGet1024? thrpt ? 10 32265609.310 ?? 400376.804? ops/s > > [2] http://cr.openjdk.java.net/~bpb/8219876/webrev.00/ > > [3] http://mail.openjdk.java.net/pipermail/nio-dev/2019-March/005954.html > [4] http://cr.openjdk.java.net/~bpb/8219876/webrev.00-01/ > > [5] http://cr.openjdk.java.net/~bpb/8219876/webrev.01/ > From brian.burkhalter at oracle.com Fri Mar 15 19:31:23 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 15 Mar 2019 12:31:23 -0700 Subject: 8219876: (bf) Improve IndexOutOfBoundsException messages in $Type$Buffer classes In-Reply-To: References: <6C0D81F3-A217-4C59-A9EB-B3EE1F70F9D3@oracle.com> <03e092da-4abe-0e90-d664-044dba455cf6@oracle.com> <00BA5DE6-C8BD-4B75-AA2E-E9CDB83E968D@oracle.com> Message-ID: <3572BEE9-5B42-4767-871D-EA3DACF5AEB7@oracle.com> Thanks, Roger. > On Mar 15, 2019, at 12:22 PM, Roger Riggs wrote: > > The latest patch [5] looks fine. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Fri Mar 15 20:32:59 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 15 Mar 2019 20:32:59 +0000 Subject: 8220738: (sc) Move ServerSocketChannelImpl remaining native method to Net Message-ID: <36e4f779-013b-e179-ccde-e76101f89394@oracle.com> ServerSocketChannelImpl has one remaining native method, accept0, to accept connections. I'd like to move this to sun.nio.ch.Net so that ServerSocketChannelImpl.c to be removed, along with native methods in SctpServerChannelImpl and UnixAsynchronousServerSocketChannelImpl that wrap it. This is the last of the "move native method" changes that are needed for NIO based SocketImpl that I mentioned in other mails. At one point, someone added a wrapper in ServerSocketChannelImpl to facilitate instrumentation, I can't quite tell what this was for but the instrumentation in JFR does not use it so I think it is safe to remove. One of the SCTP tests doesn't compile since it was changed to use InetAddress.getLoopbackAddress so that is fixed too. The webrev with the changes is here: ?? http://cr.openjdk.java.net/~alanb/8220738/webrev/index.html -Alan From brian.burkhalter at oracle.com Fri Mar 15 21:38:57 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 15 Mar 2019 14:38:57 -0700 Subject: 8220738: (sc) Move ServerSocketChannelImpl remaining native method to Net In-Reply-To: <36e4f779-013b-e179-ccde-e76101f89394@oracle.com> References: <36e4f779-013b-e179-ccde-e76101f89394@oracle.com> Message-ID: > On Mar 15, 2019, at 1:32 PM, Alan Bateman wrote: > > ServerSocketChannelImpl has one remaining native method, accept0, to accept connections. I'd like to move this to sun.nio.ch.Net so that ServerSocketChannelImpl.c to be removed, along with native methods in SctpServerChannelImpl and UnixAsynchronousServerSocketChannelImpl that wrap it. This is the last of the "move native method" changes that are needed for NIO based SocketImpl that I mentioned in other mails. > > At one point, someone added a wrapper in ServerSocketChannelImpl to facilitate instrumentation, I can't quite tell what this was for but the instrumentation in JFR does not use it so I think it is safe to remove. Probably for the now obsolete resource monitoring. > One of the SCTP tests doesn't compile since it was changed to use InetAddress.getLoopbackAddress so that is fixed too. > > The webrev with the changes is here: > http://cr.openjdk.java.net/~alanb/8220738/webrev/index.html This looks all right IFAICT. Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From christoph.langer at sap.com Wed Mar 20 16:25:55 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 20 Mar 2019 16:25:55 +0000 Subject: RFR 8213031: (zipfs) Add support for POSIX file permissions In-Reply-To: <9b3c9cfe-63e9-94ea-1af0-7ba9e2db52fd@oracle.com> References: <7b513a34196141f595cd5d194fb9d8a2@sap.com> <46af4f9d-60f9-c60d-e6f1-8fb97df3ba2e@oracle.com> <5d28b0715d2041ff892a3c44e024f120@sap.com> <8e9231ff-b7d5-bc2f-2643-713f3c670a1d@oracle.com> <3aeba9a64a434a968fc1d82a44077745@sap.com> <953449f0913340f6a94ae3d83611fd92@sap.com> <9b3c9cfe-63e9-94ea-1af0-7ba9e2db52fd@oracle.com> Message-ID: Hi Alan, I now found time to get back to the POSIX file permissions in zipfs. The goal would be to get it done for JDK13 ?? I went through your mail in details, please see my comments: > 1. By default, a zip file system will have no support for the "posix" > and "owner" views of file attributes, this means the following will fail > with UOE: > > ? PosixFileAttributes attrs = Files.readAttributes(file, > PosixFileAttributes.class); > > and the zip file system's supportedFileAttributView method will not > include "posix". Correct. > 2. Creating a zip file system with configuration parameter XXX set to > "true" will create the zip file system that supports > PosixFileAttributeView (and FileOwnerAttributeView). The current patch > names the configuration parameter "posix". That name might be misleading > as a configuration parameter as it conveys more than it actually does. > Something like "enablePosixFileAttributes" clear conveys that it enables > support for POSIX file attribute but might be a better wordy. OK. I've changed to "enablePosixFileAttributes" in my new webrev. > The value in the configuration map is documented as Boolean but I think > we are allowing it to be the string representation of a Boolean, meaning > it can be "true" or "false" like we have with the "create" parameter. I fixed the doc. > 3. The map of configurations parameters can optionally include the > parameters "defaultOwner", "defaultGroup", and "defaultPermissions" with > the default owner/group/permissions to return. These names seem okay to > me. > > For the owner/group, the parameter type can be > UserPrincipal/GroupPrincipal or strings. If the value is a String then > we need to decide if there is any validation. If I read the current > patch correctly then it doesn't do any validation - that might be okay > but minimally maybe we should disallow the empty string. I added checking for the empty string in my new webrev. > If the defaultXXX parameters aren't present then the zip file > owner/group would be a sensible default. If the zip file is on a file > store that supports FileOwnerAttributeView then we've got the owner. If > the file store supports PosixFileAttributeView then we have a group > owner. If PosixFileAttributeView is not supported then using the owner > as the group is okay. I see the current patch as a fallback to fallback > to "" but I'd prefer not have that because it will be > very confusing to diagnose if there are issues. Ok, but what shall we do then in the case of cases? That is, if the file store does not support the FileOwnerAttributeView or security permissions don't allow us to access them? Shall we fail, e.g. throw an IOException upon attempting to create a zipfs? > For defaultPermissions, the value is a Set or the > string representation. In the implementation, initPermissions can be > changed to use PosixFilePermissions.fromString as it does the > translation that we need. I don't see where it still needs to be changed. It's using PosixFilePermissions.fromString already. > 4. As an alternative to the type safe access that PosixFileAttributeView > provides, the proposal is to document the "zip" view of file attributes. > Initially, it will admit to one file attribute for the permissions. The > current patch uses the name "storedPermissions" but it might be simpler > to use "permissions" so that "zip:permissions" and "posix:permissions" > are the same when the zip entry has permissions. There's both, "storedPermissions" and "permissions. "storedPermissions" was chosen deliberately and has a different semantical meaning than "permissions". The former one will reflect the actual permission value on a zip entry, e.g. it can be null. The latter one will use the default, in case no permission information is associated with the zip entry. > With this support you can write code like this: > ??? Set perms = (Set) > Files.getAttribute(file, "zip:permissions"); > > The cast is ugly of course but that's the consequence of not exposing > ZipFileAttributes in the API so there is no type token to specify on the > RHS. That should work with the proposed patch. > Documenting the "zip" view brings up a few issues, e.g. will > Files.readAttributes(file, "zip:*") reveal more than "permissions". For > this API it is okay for the map to attributes beyond the specified list. I guess we should reveal all attributes of a zip view in the documentation. > 5. There will be no support for specifying as POSIX FileAttribute to > createFile or createDirectory to atomically set the permissions when > creating a new file/directory, UOE will thrown as is is now. Nope. It will work with the current state of the patch. Here is an updated webrev: http://cr.openjdk.java.net/~clanger/webrevs/8213031.8/ What's next? Thanks Christoph From Alan.Bateman at oracle.com Thu Mar 21 12:33:33 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 21 Mar 2019 12:33:33 +0000 Subject: 8221252: (sc) SocketChannel and its socket adaptor need to handle connection reset Message-ID: This is, I hope, the last patch in the series to prepare the code in sun.nio.ch for the NIO based SocketImpl. This last patch mostly concerns the behavior when reading after a connection reset has been detected. SocketChannel has not historically done any special handling for case case so reading after a connection reset behaves inconsistently (it returns whatever the operating system, e.g. Windows returns an error, Unix/macOS return -1/EOF). In classic networking, Socket::getInputStream specifies that subsequent reads throws IOException so that the read-after-reset behaves consistently on all platforms. The proposal here is to update SocketChannel read to implement the behavior specified by Socket::getInputStream, the rational is that the socket adaptor (returned by SocketChannel::socket) needs to implement that behavior anyway. This change helps the NIO based SocketImpl effort as it allows the same underlying I/O methods can be used. There are a fews cleanups in this patch but nothing of any significance: Net.pollConnect is changed to return a boolean rather than 0/1 and Net is also updated to new setSocketOption/getSocketOption methods to avoid needing to specify the "UNSPEC" family. If they are a distraction then I can move them to another patch, they are only included here to align jdk/jdk with the minor cleanups in the niosocketimpl-branch. The webrev with the changes is here. The new test exercises SocketChannel.read and the socket adaptor read/available methods for cases where the connection is reset. http://cr.openjdk.java.net/~alanb/8221252/webrev/ -Alan From brian.burkhalter at oracle.com Thu Mar 21 21:50:43 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 21 Mar 2019 14:50:43 -0700 Subject: 8221252: (sc) SocketChannel and its socket adaptor need to handle connection reset In-Reply-To: References: Message-ID: <7F5F95F7-2A10-47B4-A957-93C2BEAA16A9@oracle.com> > On Mar 21, 2019, at 5:33 AM, Alan Bateman wrote: > > This is, I hope, the last patch in the series to prepare the code in sun.nio.ch for the NIO based SocketImpl. This last patch mostly concerns the behavior when reading after a connection reset has been detected. [?] > > The webrev with the changes is here. The new test exercises SocketChannel.read and the socket adaptor read/available methods for cases where the connection is reset. > > http://cr.openjdk.java.net/~alanb/8221252/webrev/ I don?t see any problems here. Some minor nits: * Copyright year needs to be updated in IOStatus, UnixAsynchronousSocketChannelImpl, and SctpChannelImpl. * ConnectionReset test: ? Maybe interchange lines 32 and 33. ? I suppose the println() calls which are the first statements in the test methods could be removed. ? The test method names might be slightly more descriptive, e.g, testSocketChannelReadNoBytes (or testSocketChannelReadNull) and testSocketChannelReadBytes (or testSocketChannelRead) instead of testSocketChannelRead1 and testSocketChannelRead2, respectively. ? Typos: line 99 ?connectin? -> ?connection? and line 188 ?teh? => ?the? Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Fri Mar 22 10:44:10 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 22 Mar 2019 10:44:10 +0000 Subject: 8221252: (sc) SocketChannel and its socket adaptor need to handle connection reset In-Reply-To: <7F5F95F7-2A10-47B4-A957-93C2BEAA16A9@oracle.com> References: <7F5F95F7-2A10-47B4-A957-93C2BEAA16A9@oracle.com> Message-ID: <77fa3dfc-f997-66f0-e4ff-a3da6bf942f2@oracle.com> On 21/03/2019 21:50, Brian Burkhalter wrote: > > > I don?t see any problems here. Thanks. > Some minor nits: > > * Copyright year needs to be updated in IOStatus, > UnixAsynchronousSocketChannelImpl, and SctpChannelImpl. Will do (although we should really automate this or update in bulk on a regular basis). > > * ConnectionReset test: > ??Maybe interchange lines 32 and 33. > ??I suppose the println() calls which are the first statements in the > test methods could be removed. They are helpful in the test output as TestNG prints the status at the end of the test and sometimes not obvious where the start is. Some people like to use @BeforeTest to print the test name but that leads to additional output that I don't think can be suppresed. > ??The test method names might be slightly more descriptive, e.g, > testSocketChannelReadNoBytes (or ?testSocketChannelReadNull) > and?testSocketChannelReadBytes (or testSocketChannelRead) instead of > ?testSocketChannelRead1 and ?testSocketChannelRead2, respectively. Okay, I'll do that. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Fri Mar 22 15:15:34 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 22 Mar 2019 08:15:34 -0700 Subject: 8221252: (sc) SocketChannel and its socket adaptor need to handle connection reset In-Reply-To: <77fa3dfc-f997-66f0-e4ff-a3da6bf942f2@oracle.com> References: <7F5F95F7-2A10-47B4-A957-93C2BEAA16A9@oracle.com> <77fa3dfc-f997-66f0-e4ff-a3da6bf942f2@oracle.com> Message-ID: > On Mar 22, 2019, at 3:44 AM, Alan Bateman wrote: > >> * Copyright year needs to be updated in IOStatus, UnixAsynchronousSocketChannelImpl, and SctpChannelImpl. > Will do (although we should really automate this or update in bulk on a regular basis). +1 >> * ConnectionReset test: >> ? Maybe interchange lines 32 and 33. >> ? I suppose the println() calls which are the first statements in the test methods could be removed. > They are helpful in the test output as TestNG prints the status at the end of the test and sometimes not obvious where the start is. Some people like to use @BeforeTest to print the test name but that leads to additional output that I don't think can be suppresed. I see. Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.hefty at intel.com Wed Mar 27 01:12:56 2019 From: sean.hefty at intel.com (Hefty, Sean) Date: Wed, 27 Mar 2019 01:12:56 +0000 Subject: rsocket Issue #2 In-Reply-To: <448ef95f-cf07-128c-8f16-149d69c801f8@oracle.com> References: <448ef95f-cf07-128c-8f16-149d69c801f8@oracle.com> Message-ID: <1828884A29C6694DAF28B7E6B8A82373B3E09291@ORSMSX109.amr.corp.intel.com> I have a patch to address the connection progress issue. I've opened a pull request against the upstream rsocket code here: https://github.com/linux-rdma/rdma-core/pull/506 I've included a test app as part of the pull request. But if you can verify that the changes work with your tests, that would be great. I believe with this change, the problem you were seeing with a blocking rrecv() call returning EAGAIN should no longer occur. There is still no fix for the rpoll() issue reported below. I'm not exactly sure where the problem is that causes that yet. - Sean > -----Original Message----- > From: Chris Hegarty [mailto:chris.hegarty at oracle.com] > Sent: Wednesday, February 13, 2019 10:00 AM > To: Lu, Yingqi ; nio-dev at openjdk.java.net; Hefty, Sean > > Cc: Viswanathan, Sandhya ; Kaczmarek, Eric > ; Aundhe, Shirish > Subject: rsocket Issue #2 > > Hi Sean, Lucy, > > In an attempt to work-around issue #2 (non-blocking connect not making > progress, reported in [1] ), I have run into a separate issue with > `rpoll`. I think it is a bug, and it will make working-around issue #2 > much more difficult ( maybe impracticable ). > > The behaviour I observe is that, if more than one thread is blocked in > a `rpoll` call ( with the same socket and events), and the event is > triggered, then only one thread ( rpoll ) will wakeup. I've put together > a native test: > http://cr.openjdk.java.net/~chegar/rsocket/testBipollar.c > > This is an issue for the Java API that allows a channel to be registered > with more than one selector. It is also a possible issue with a selector > racing with finishConnect. These scenarios are not all that common, but > still possible. > > The `rpoll` behaviour I observe is clearly different than regular > `poll` ( which will wake up all waiters ). Is this a bug, or expected > behaviour of the thread-less rsocket implementation? > > -Chris. > > [1] > https://mail.openjdk.java.net/pipermail/nio-dev/2018-December/005651.html From brian.burkhalter at oracle.com Wed Mar 27 18:58:32 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 27 Mar 2019 11:58:32 -0700 Subject: 8221531: Incorrect copyright header in src/java.base/windows/native/libnio/ch/FileChannelImpl.c Message-ID: <45D03D70-A437-43DA-8C60-2A615002748A@oracle.com> https://bugs.openjdk.java.net/browse/JDK-8221531 Add a comma after the more recent copyright year. Patch: --- a/src/java.base/windows/native/libnio/ch/FileChannelImpl.c +++ b/src/java.base/windows/native/libnio/ch/FileChannelImpl.c @@ -1,5 +1,5 @@ /* - * Copyright (c) 2000, 2018 Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2000, 2018, 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 Verification: sh make/scripts/lic_check.sh -gplcp src/java.base/windows/native/libnio/ch/FileChannelImpl.c ### Checking copyright notice in the file: src/java.base/windows/native/libnio/ch/FileChannelImpl.c ### SUCCESS: The license header for /Users/bpb/Work/CoreLibs/jdk/jdk/open/src/java.base/windows/native/libnio/ch/FileChannelImpl.c has been verified. ### Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From brent.christian at oracle.com Wed Mar 27 19:03:58 2019 From: brent.christian at oracle.com (Brent Christian) Date: Wed, 27 Mar 2019 12:03:58 -0700 Subject: 8221531: Incorrect copyright header in src/java.base/windows/native/libnio/ch/FileChannelImpl.c In-Reply-To: <45D03D70-A437-43DA-8C60-2A615002748A@oracle.com> References: <45D03D70-A437-43DA-8C60-2A615002748A@oracle.com> Message-ID: <01b19019-6698-7260-ac10-e67fdc68281d@oracle.com> +1 -Brent On 3/27/19 11:58 AM, Brian Burkhalter wrote: > https://bugs.openjdk.java.net/browse/JDK-8221531 > > Add a comma after the more recent copyright year. > > Patch: > > --- a/src/java.base/windows/native/libnio/ch/FileChannelImpl.c > +++ b/src/java.base/windows/native/libnio/ch/FileChannelImpl.c > @@ -1,5 +1,5 @@ > ?/* > - * Copyright (c) 2000, 2018 Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 2000, 2018, 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 > > Verification: > > sh make/scripts/lic_check.sh -gplcp > src/java.base/windows/native/libnio/ch/FileChannelImpl.c > ### Checking copyright notice in the file: > src/java.base/windows/native/libnio/ch/FileChannelImpl.c > ### > SUCCESS: The license header for > /Users/bpb/Work/CoreLibs/jdk/jdk/open/src/java.base/windows/native/libnio/ch/FileChannelImpl.c > has been verified. > ### > > Thanks, > > Brian From lance.andersen at oracle.com Wed Mar 27 19:02:40 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Wed, 27 Mar 2019 15:02:40 -0400 Subject: 8221531: Incorrect copyright header in src/java.base/windows/native/libnio/ch/FileChannelImpl.c In-Reply-To: <45D03D70-A437-43DA-8C60-2A615002748A@oracle.com> References: <45D03D70-A437-43DA-8C60-2A615002748A@oracle.com> Message-ID: <7BA9A919-5DBF-42C7-A8AD-A6CF3FEF657D@oracle.com> +1 > On Mar 27, 2019, at 2:58 PM, Brian Burkhalter wrote: > > https://bugs.openjdk.java.net/browse/JDK-8221531 > > Add a comma after the more recent copyright year. > > Patch: > > --- a/src/java.base/windows/native/libnio/ch/FileChannelImpl.c > +++ b/src/java.base/windows/native/libnio/ch/FileChannelImpl.c > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2000, 2018 Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2000, 2018, 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 > > Verification: > > sh make/scripts/lic_check.sh -gplcp src/java.base/windows/native/libnio/ch/FileChannelImpl.c > ### Checking copyright notice in the file: src/java.base/windows/native/libnio/ch/FileChannelImpl.c > ### > SUCCESS: The license header for /Users/bpb/Work/CoreLibs/jdk/jdk/open/src/java.base/windows/native/libnio/ch/FileChannelImpl.c has been verified. > ### > > Thanks, > > Brian Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: oracle_sig_logo.gif Type: image/gif Size: 658 bytes Desc: not available URL: From brian.burkhalter at oracle.com Thu Mar 28 21:29:56 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 28 Mar 2019 14:29:56 -0700 Subject: 8220477: Channels.newWriter() does not close if underlying channel throws an IOException Message-ID: For the issue [1] please review the proposed patch [2]. The change is to catch an IOException thrown by implClose() and mark the {en,de}coder as closed anyway. Lots of lines of test for a small change! Thanks, Brian [1] https://bugs.openjdk.java.net/browse/JDK-8220477 [2] http://cr.openjdk.java.net/~bpb/8220477/webrev.00/ From Alan.Bateman at oracle.com Fri Mar 29 07:35:27 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 29 Mar 2019 07:35:27 +0000 Subject: 8220477: Channels.newWriter() does not close if underlying channel throws an IOException In-Reply-To: References: Message-ID: <94010bf5-c219-5f67-f939-b8757e418adb@oracle.com> On 28/03/2019 21:29, Brian Burkhalter wrote: > For the issue [1] please review the proposed patch [2]. The change is to catch an IOException thrown by implClose() and mark the {en,de}coder as closed anyway. Lots of lines of test for a small change! > Looks good. As you are there, would you mind fixing formatting in StreamDecoder? I can't tell what happened to it but it looks like the intendation has been removed from L230+ onwards (I only noticed it when looking at the implClose at the end of file). -Alan From brian.burkhalter at oracle.com Fri Mar 29 14:34:20 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 29 Mar 2019 07:34:20 -0700 Subject: 8220477: Channels.newWriter() does not close if underlying channel throws an IOException In-Reply-To: <94010bf5-c219-5f67-f939-b8757e418adb@oracle.com> References: <94010bf5-c219-5f67-f939-b8757e418adb@oracle.com> Message-ID: <1A18A1EC-D7C8-4AA9-AFB8-5DB39166C6BC@oracle.com> > On Mar 29, 2019, at 12:35 AM, Alan Bateman wrote: > > On 28/03/2019 21:29, Brian Burkhalter wrote: >> For the issue [1] please review the proposed patch [2]. The change is to catch an IOException thrown by implClose() and mark the {en,de}coder as closed anyway. Lots of lines of test for a small change! >> > Looks good. As you are there, would you mind fixing formatting in StreamDecoder? I can't tell what happened to it but it looks like the intendation has been removed from L230+ onwards (I only noticed it when looking at the implClose at the end of file). Yes I can fix that. After I posted this RFR, I ran the patch through all the testing tiers and with this patch the test sun/nio/cs/StreamEncoderClose.java fails at line 50. I need to think whether this indicates a problem with the patch or the StreamEncoderClose test is incorrect. Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Fri Mar 29 23:49:02 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 29 Mar 2019 16:49:02 -0700 Subject: 8218418: (fs) Files.createSymbolicLink should use SYMBOLIC_LINK_FLAG_ALLOW_UNPRIVILEGED_CREATE (win) In-Reply-To: <4130f5d7-60d6-532e-f5bc-6a58769bf1f0@oracle.com> References: <1F64D02D-DFE9-4479-A979-C3D1375E9A42@oracle.com> <4130f5d7-60d6-532e-f5bc-6a58769bf1f0@oracle.com> Message-ID: <184848D7-307E-46B8-9DB5-D56A40E9A8A8@oracle.com> > On Feb 15, 2019, at 12:24 AM, Alan Bateman wrote: > > On 15/02/2019 00:42, Brian Burkhalter wrote: >> https://bugs.openjdk.java.net/browse/JDK-8218418 >> >> The proposed change below ran without error through the jdk_core tests on Windows. Presumably it is covered sufficiently by test/jdk/java/nio/file/Files/Links.java so the issue could be labelled noreg-other. > I think the fix looks okay but I think it needs checking in the different configurations (process has the privilege, does not have the privilege, and "developer mode") to be sure. This isn't something we can setup in the jtreg tests. As detailed in the comments I just added to the issue, I was able to verify in Windows 10 that the flag works as desired: it allows a standard user to create a symbolic link to an entity for which it has permission provided that the SYMBOLIC_LINK_FLAG_ALLOW_UNPRIVILEGED_CREATE flag is present and Developer Mode is enabled. If this flag is not provided or Developer Mode is not enabled, a standard user cannot create a symbolic link. Therefore I think that the patch is good to go as-is. Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From 1142763824 at qq.com Sat Mar 30 05:54:50 2019 From: 1142763824 at qq.com (=?ISO-8859-1?B?U21hcnRMZWU=?=) Date: Sat, 30 Mar 2019 13:54:50 +0800 Subject: Just confirmation Message-ID: -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Sat Mar 30 09:12:17 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 30 Mar 2019 09:12:17 +0000 Subject: 8218418: (fs) Files.createSymbolicLink should use SYMBOLIC_LINK_FLAG_ALLOW_UNPRIVILEGED_CREATE (win) In-Reply-To: <184848D7-307E-46B8-9DB5-D56A40E9A8A8@oracle.com> References: <1F64D02D-DFE9-4479-A979-C3D1375E9A42@oracle.com> <4130f5d7-60d6-532e-f5bc-6a58769bf1f0@oracle.com> <184848D7-307E-46B8-9DB5-D56A40E9A8A8@oracle.com> Message-ID: <1953890b-e01e-1bd7-bdd6-8c1b63eedf7f@oracle.com> On 29/03/2019 23:49, Brian Burkhalter wrote: > >> On Feb 15, 2019, at 12:24 AM, Alan Bateman > > wrote: >> >> On 15/02/2019 00:42, Brian Burkhalter wrote: >>> https://bugs.openjdk.java.net/browse/JDK-8218418 >>> >>> The proposed change below ran without error through the jdk_core >>> tests on Windows. Presumably it is covered sufficiently >>> bytest/jdk/java/nio/file/Files/Links.java so the issue could be >>> labelled noreg-other. >> I think the fix looks okay but I think it needs checking in the >> different configurations (process has the privilege, does not have >> the privilege, and "developer mode") to be sure. This isn't something >> we can setup in the jtreg tests. > > As detailed in the comments I just added to the issue, I was able to > verify in Windows 10 that the flag works as desired: it allows a > standard user to create a symbolic link to an entity for which it has > permission provided that > the?SYMBOLIC_LINK_FLAG_ALLOW_UNPRIVILEGED_CREATE flag is present and > Developer Mode is enabled. If this flag is not provided or Developer > Mode is not enabled, a standard user cannot create a symbolic link. > Therefore I think that the patch is good to go as-is. > Good, thanks for checking. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Sun Mar 31 15:29:19 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 31 Mar 2019 16:29:19 +0100 Subject: RFR 8213031: (zipfs) Add support for POSIX file permissions In-Reply-To: References: <7b513a34196141f595cd5d194fb9d8a2@sap.com> <46af4f9d-60f9-c60d-e6f1-8fb97df3ba2e@oracle.com> <5d28b0715d2041ff892a3c44e024f120@sap.com> <8e9231ff-b7d5-bc2f-2643-713f3c670a1d@oracle.com> <3aeba9a64a434a968fc1d82a44077745@sap.com> <953449f0913340f6a94ae3d83611fd92@sap.com> <9b3c9cfe-63e9-94ea-1af0-7ba9e2db52fd@oracle.com> Message-ID: On 20/03/2019 16:25, Langer, Christoph wrote: > Hi Alan, > > I now found time to get back to the POSIX file permissions in zipfs. The goal would be to get it done for JDK13 ?? > > : > > Here is an updated webrev: http://cr.openjdk.java.net/~clanger/webrevs/8213031.8/ > > What's next? > I skimmed through the updated webrev and read your latest comments/replies and I think we are close. One thing that is puzzling is that ZipFileAttributeView/ZipFileAttributes extend PosixFileAttributeView/PosixFileAttributes. I don't think that will work because the "zip" view is supported by default whereas "posix" view needs the file system to be created with enablePosixFileAttributes=true. I saw your comment about naming the file permissions attribute "storedPermissions" in the zip view but if the zip and posix view are separated then I think it would be clearer to name it "permissions" in the zip view. If code is using Files.getAttribute then it will need the view name so they won't get mixed up. You asked about the fallback when defaultOwner/defaultGroup aren't set. If getOwner fails with an IOException then I think that exception should be propagated. The UOE case will fallback to the value of "user.name". I think the fallback for the group owner should be the file owner rather than " "". The default.policy file will need to be updated to grant jdk.zipfs RuntimePermission("accessUserInfo") so that you won't need to deal with security exceptions. As regards next steps then I think we need to agree the spec changes, as in the the javadoc in module-info.java. Once we have the spec agreed then the CSR can be updated and finalized. The code review can be done in parallel of course. I think Lance is going to help review the changes. -Alan