From Alan.Bateman at oracle.com Sun Sep 1 08:16:20 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 1 Sep 2019 09:16:20 +0100 Subject: 8229280: Test failures on several linux hosts after JDK-8181493 In-Reply-To: References: <2D854054-B445-406B-8777-4D1DA2F95137@oracle.com> <97F6E4AD-3802-4A2C-8043-3158DA323B37@oracle.com> <88BB88A0-AE86-478F-8B9C-EA45F4B7A8C1@oracle.com> <018859AB-83DD-4704-A92A-8FFB50B35970@oracle.com> <7b4c2bd4-4e3d-70f0-9d8b-b0d24ae038a0@oracle.com> <8DE2D4E9-E312-4E73-A692-DE35141BFC2A@oracle.com> <638E1D14-E6F7-4BD1-97F2-1579F437D930@oracle.com> Message-ID: On 29/08/2019 01:56, Brian Burkhalter wrote: > > Done [1]. The test description needs `@modules java.base/sun.nio.fs:+open` to open the package to the test. That should allow L42-50 to be cleaned up. > Note however that futimens() can be supported without it actually > being able to set the timestamps to nanosecond precision, e.g., for > HFS file systems on macOS. Therefore the test will still pass if the > actual and expected values are not equal due to truncation of a > multiple of three digits of precision. Is there any way that we could use the FileStore::type to target this test to specify file systems that are known to support nanosecond precision? -Alan From vkempik at azul.com Tue Sep 3 16:00:19 2019 From: vkempik at azul.com (Vladimir Kempik) Date: Tue, 3 Sep 2019 16:00:19 +0000 Subject: RFR: 8229872: (fs) Increase buffer size used with getmntent In-Reply-To: References: <1DF90E8C-07FB-4809-A2AD-04D9D0F2FF0D@azul.com> <87ftlxtllz.fsf@oldenburg2.str.redhat.com> <943b19d2-4846-3552-ab3d-6aaa598ece9e@oracle.com> <87v9uts4bz.fsf@oldenburg2.str.redhat.com> <2A80DD4F-6D09-477F-920C-B070601FBA54@azul.com> <87lfvps392.fsf@oldenburg2.str.redhat.com> <0FB89DBB-566C-4E32-8131-C15FA659022D@azul.com> <8736hvoqa3.fsf@oldenburg2.str.redhat.com> <20BDB142-8E77-4886-9902-CB1DE5CC4930@azul.com> <503abeab-0aae-937a-5c4b-b022e5f10dd1@oracle.com> <87a7bzsyyh.fsf@oldenburg2.str.redhat.com> <0D734383-604F-414C-9F5D-27E5C617E04F@azul.com> Message-ID: <05113D4C-1258-4502-9D5F-D1BE4C4BA5ED@azul.com> Hello Please review v4 of the patch http://cr.openjdk.java.net/~vkempik/8229872/webrev.04/ diffs vs v3: - rewind and getline moved to UnixNativeDispatcher - some error handling in rewind, but according to manpage&internet, ferror doesn?t set errno, so I can?t get details of error, only the fact if it happened or not. - bigger comment on getlinelen Thanks, Vladimir 23 ???. 2019 ?., ? 18:47, Alan Bateman > ???????(?): On 23/08/2019 16:18, Vladimir Kempik wrote: Hello I?m not sure about full version of getline. getline requires malloced buffer and may update passed in buffer to a new size (via realloc) so it?s not safe to pass anything from java, (even NativeBuffer i think) to it. two ways to work it around: 1) minimal version of getline, like I did 2) in jni, allocate new, malloced buffer with same size as incoming buffer. pass it to getline. after getline finished, update incoming buffer with proper data (and increase it if needed). will still need malloc/free Alan, you really sure you want it to go second path while there is no consumer of full version of getline ? I think we should introducing ad hoc native methods if possible. The native methods in this area are meant to be simple wrappers of syscall or libc function. There are few exceptions of course but the original intention was to be able to do as much in Java as possible. It should also make it easier to move this code to Project Panama in the future (there is already a version of UnixNativeDispatcher in that project). You are right that getline is a bit awkward because it is essentially returning both a pointer and a size. If we can't come up with something better then getlinelen might be okay but it needs cleanup and the comment changed to reflect what it does. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Tue Sep 3 17:10:03 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 3 Sep 2019 18:10:03 +0100 Subject: RFR: 8229872: (fs) Increase buffer size used with getmntent In-Reply-To: <05113D4C-1258-4502-9D5F-D1BE4C4BA5ED@azul.com> References: <1DF90E8C-07FB-4809-A2AD-04D9D0F2FF0D@azul.com> <87ftlxtllz.fsf@oldenburg2.str.redhat.com> <943b19d2-4846-3552-ab3d-6aaa598ece9e@oracle.com> <87v9uts4bz.fsf@oldenburg2.str.redhat.com> <2A80DD4F-6D09-477F-920C-B070601FBA54@azul.com> <87lfvps392.fsf@oldenburg2.str.redhat.com> <0FB89DBB-566C-4E32-8131-C15FA659022D@azul.com> <8736hvoqa3.fsf@oldenburg2.str.redhat.com> <20BDB142-8E77-4886-9902-CB1DE5CC4930@azul.com> <503abeab-0aae-937a-5c4b-b022e5f10dd1@oracle.com> <87a7bzsyyh.fsf@oldenburg2.str.redhat.com> <0D734383-604F-414C-9F5D-27E5C617E04F@azul.com> <05113D4C-1258-4502-9D5F-D1BE4C4BA5ED@azul.com> Message-ID: <4840e25c-4794-22bb-bc62-d1103d1988a1@oracle.com> On 03/09/2019 17:00, Vladimir Kempik wrote: > Hello > > Please review v4 of the patch > > http://cr.openjdk.java.net/~vkempik/8229872/webrev.04/ > > diffs vs v3: > - rewind and getline moved to UnixNativeDispatcher > - some error handling in rewind, but according to manpage&internet, > ferror doesn?t set errno, so I can?t get details of error, only the > fact if it happened or not. > - bigger comment on getlinelen > I think the approach in this version is good, just need to agree a few details. I think it would be better if LinuxNativeDispatcher getmntent were called with buf and buflen rather than maxLineLen. That is, use NativeBuffers.getNativeBuffer to get a uffer to pass to the native method. That keeps the native method simple, consistent with existing code, and avoids the discussion about what happens when malloc fails. In UnixNativeDispatcher then it would be nicer if rewind and getlinelen were after the fopen/fclose functions so that all the FILE* functions are together. The return from getlinelen needs to be a jlong rather than a long. Can you reformat the comments in both native functions to be consistent with the existing code? -Alan From vkempik at azul.com Tue Sep 3 18:58:55 2019 From: vkempik at azul.com (Vladimir Kempik) Date: Tue, 3 Sep 2019 18:58:55 +0000 Subject: RFR: 8229872: (fs) Increase buffer size used with getmntent In-Reply-To: <4840e25c-4794-22bb-bc62-d1103d1988a1@oracle.com> References: <1DF90E8C-07FB-4809-A2AD-04D9D0F2FF0D@azul.com> <87ftlxtllz.fsf@oldenburg2.str.redhat.com> <943b19d2-4846-3552-ab3d-6aaa598ece9e@oracle.com> <87v9uts4bz.fsf@oldenburg2.str.redhat.com> <2A80DD4F-6D09-477F-920C-B070601FBA54@azul.com> <87lfvps392.fsf@oldenburg2.str.redhat.com> <0FB89DBB-566C-4E32-8131-C15FA659022D@azul.com> <8736hvoqa3.fsf@oldenburg2.str.redhat.com> <20BDB142-8E77-4886-9902-CB1DE5CC4930@azul.com> <503abeab-0aae-937a-5c4b-b022e5f10dd1@oracle.com> <87a7bzsyyh.fsf@oldenburg2.str.redhat.com> <0D734383-604F-414C-9F5D-27E5C617E04F@azul.com> <05113D4C-1258-4502-9D5F-D1BE4C4BA5ED@azul.com> <4840e25c-4794-22bb-bc62-d1103d1988a1@oracle.com> Message-ID: Hello. Looks reasonable. Just one question If I pass NativeBuffers.getNativeBuffer to getmntent and getmntent will decide to call realloc on that buffer. Will such NativeBuffer then be pointing to freed memory? If such NativeBuffer object gets destructed, will we get double free error? Thanks, Vladimir. Alan Bateman 3 ???????? 2019 ?. 20:10:45 ???????: > On 03/09/2019 17:00, Vladimir Kempik wrote: >> Hello >> >> >> Please review v4 of the patch >> >> >> http://cr.openjdk.java.net/~vkempik/8229872/webrev.04/ >> >> >> diffs vs v3: >> - rewind and getline moved to UnixNativeDispatcher >> - some error handling in rewind, but according to manpage&internet, >> ferror doesn?t set errno, so I can?t get details of error, only the >> fact if it happened or not. >> - bigger comment on getlinelen > I think the approach in this version is good, just need to agree a few > details. > > I think it would be better if LinuxNativeDispatcher getmntent were > called with buf and buflen rather than maxLineLen. That is, use > NativeBuffers.getNativeBuffer to get a uffer to pass to the native > method. That keeps the native method simple, consistent with existing > code, and avoids the discussion about what happens when malloc fails. > > In UnixNativeDispatcher then it would be nicer if rewind and getlinelen > were after the fopen/fclose functions so that all the FILE* functions > are together. > The return from getlinelen needs to be a jlong rather than a long. > Can you reformat the comments in both native functions to be consistent > with the existing code? > > -Alan From christoph.langer at sap.com Tue Sep 3 19:10:40 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 3 Sep 2019 19:10:40 +0000 Subject: RFR: 8229887: ZIP FS cannot replace an entry in a that was added via the STORED method In-Reply-To: References: Message-ID: Hi Lance, Alan, would you mind if I take care of backporting this fix to jdk13u and jdk11u? Thanks Christoph From: nio-dev On Behalf Of Lance Andersen Sent: Mittwoch, 21. August 2019 16:46 To: Alan Bateman Cc: nio-dev Subject: Re: RFR: 8229887: ZIP FS cannot replace an entry in a that was added via the STORED method On Aug 20, 2019, at 7:34 AM, Alan Bateman > wrote: On 19/08/2019 21:48, Lance Andersen wrote: Hi The following patch for JDK-8229887 addresses an issue introduced by the performance fix in https://bugs.openjdk.java.net/browse/JDK-8222532 resulting in an error when trying to replace an entry in a ZIP/JAR file that was added with no-compression. The webrev can be found at http://cr.openjdk.java.net/~lancea/8229887/webrev.00/index.html The update to ZipFileSystem looks good. Thank you Alan I think the test needs a bit of work and needs to test updating zip files where all entries are stored, all entries are deflated, and a mix of the two. I've created a test that does this if you need it. A revised webrev can be found at: http://cr.openjdk.java.net/~lancea/8229887/webrev.01/index.html This cleans up the existing test and adds some additional tests that were contributed by Alan. Mach5 tier1-3 are all clean Best Lance -Alan [cid:image001.gif at 01D5629C.097DB070] 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: image001.gif Type: image/gif Size: 658 bytes Desc: image001.gif URL: From Alan.Bateman at oracle.com Tue Sep 3 19:23:12 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 3 Sep 2019 20:23:12 +0100 Subject: RFR: 8229872: (fs) Increase buffer size used with getmntent In-Reply-To: References: <1DF90E8C-07FB-4809-A2AD-04D9D0F2FF0D@azul.com> <87ftlxtllz.fsf@oldenburg2.str.redhat.com> <943b19d2-4846-3552-ab3d-6aaa598ece9e@oracle.com> <87v9uts4bz.fsf@oldenburg2.str.redhat.com> <2A80DD4F-6D09-477F-920C-B070601FBA54@azul.com> <87lfvps392.fsf@oldenburg2.str.redhat.com> <0FB89DBB-566C-4E32-8131-C15FA659022D@azul.com> <8736hvoqa3.fsf@oldenburg2.str.redhat.com> <20BDB142-8E77-4886-9902-CB1DE5CC4930@azul.com> <503abeab-0aae-937a-5c4b-b022e5f10dd1@oracle.com> <87a7bzsyyh.fsf@oldenburg2.str.redhat.com> <0D734383-604F-414C-9F5D-27E5C617E04F@azul.com> <05113D4C-1258-4502-9D5F-D1BE4C4BA5ED@azul.com> <4840e25c-4794-22bb-bc62-d1103d1988a1@oracle.com> Message-ID: On 03/09/2019 19:58, Vladimir Kempik wrote: > Hello. > Looks reasonable. > Just one question > If I pass NativeBuffers.getNativeBuffer to getmntent and getmntent will decide to call realloc on that buffer. > Will such NativeBuffer then be pointing to freed memory? > > If such NativeBuffer object gets destructed, will we get double free error? > Ah yes, you did mention the realloc in one of the earlier mails and that isn't going to work with NativeBuffer. In that case, let's go with that part of the patch and maybe a comment reminds the reader that it may realloc. -Alan From lance.andersen at oracle.com Tue Sep 3 21:00:11 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Tue, 3 Sep 2019 17:00:11 -0400 Subject: RFR: 8229887: ZIP FS cannot replace an entry in a that was added via the STORED method In-Reply-To: References: Message-ID: Hi Christoph, > On Sep 3, 2019, at 3:10 PM, Langer, Christoph wrote: > > Hi Lance, Alan, > > would you mind if I take care of backporting this fix to jdk13u and jdk11u? I think that is your call as to when you are ready to backport. I might wait a bit longer myself o. While I am comfortable with the fix, it might give a bit more time to make sure there are no additional speed bumps. Best Lance > > Thanks > Christoph > > From: nio-dev > On Behalf Of Lance Andersen > Sent: Mittwoch, 21. August 2019 16:46 > To: Alan Bateman > > Cc: nio-dev > > Subject: Re: RFR: 8229887: ZIP FS cannot replace an entry in a that was added via the STORED method > > > On Aug 20, 2019, at 7:34 AM, Alan Bateman > wrote: > > On 19/08/2019 21:48, Lance Andersen wrote: > > Hi > > The following patch for JDK-8229887 addresses an issue introduced by the performance fix inhttps://bugs.openjdk.java.net/browse/JDK-8222532 resulting in an error when trying to replace an entry in a ZIP/JAR file that was added with no-compression. > > The webrev can be found at http://cr.openjdk.java.net/~lancea/8229887/webrev.00/index.html > > The update to ZipFileSystem looks good. > > Thank you Alan > > > I think the test needs a bit of work and needs to test updating zip files where all entries are stored, all entries are deflated, and a mix of the two. I've created a test that does this if you need it. > > A revised webrev can be found at: http://cr.openjdk.java.net/~lancea/8229887/webrev.01/index.html > > This cleans up the existing test and adds some additional tests that were contributed by Alan. > > Mach5 tier1-3 are all clean > > Best > Lance > > > > -Alan > > > > 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 > > > > 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 christoph.langer at sap.com Wed Sep 4 07:22:46 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 4 Sep 2019 07:22:46 +0000 Subject: RFR: 8229887: ZIP FS cannot replace an entry in a that was added via the STORED method In-Reply-To: References: Message-ID: Hi Lance, thanks for your comments. I?ve requested the patches for jdk13u and jdk11u then. By default they?d reach the Jan 2020 update release, so they?ll get some time to bake in there. Actually, since this patch fixes a regression that has been introduced just recently, I could imagine that the fix would even be a candidate for the October patches. It looks quite obvious and I don?t think that there?s a huge performance risk. But I don?t want to take this decision on my own ?? Best regards Christoph From: Lance Andersen Sent: Dienstag, 3. September 2019 23:00 To: Langer, Christoph Cc: Alan Bateman ; nio-dev Subject: Re: RFR: 8229887: ZIP FS cannot replace an entry in a that was added via the STORED method Hi Christoph, On Sep 3, 2019, at 3:10 PM, Langer, Christoph > wrote: Hi Lance, Alan, would you mind if I take care of backporting this fix to jdk13u and jdk11u? I think that is your call as to when you are ready to backport. I might wait a bit longer myself o. While I am comfortable with the fix, it might give a bit more time to make sure there are no additional speed bumps. Best Lance Thanks Christoph From: nio-dev > On Behalf Of Lance Andersen Sent: Mittwoch, 21. August 2019 16:46 To: Alan Bateman > Cc: nio-dev > Subject: Re: RFR: 8229887: ZIP FS cannot replace an entry in a that was added via the STORED method On Aug 20, 2019, at 7:34 AM, Alan Bateman > wrote: On 19/08/2019 21:48, Lance Andersen wrote: Hi The following patch for JDK-8229887 addresses an issue introduced by the performance fix inhttps://bugs.openjdk.java.net/browse/JDK-8222532 resulting in an error when trying to replace an entry in a ZIP/JAR file that was added with no-compression. The webrev can be found at http://cr.openjdk.java.net/~lancea/8229887/webrev.00/index.html The update to ZipFileSystem looks good. Thank you Alan I think the test needs a bit of work and needs to test updating zip files where all entries are stored, all entries are deflated, and a mix of the two. I've created a test that does this if you need it. A revised webrev can be found at: http://cr.openjdk.java.net/~lancea/8229887/webrev.01/index.html This cleans up the existing test and adds some additional tests that were contributed by Alan. Mach5 tier1-3 are all clean Best Lance -Alan 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 [cid:image001.gif at 01D56302.4FCCE490] 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: image001.gif Type: image/gif Size: 658 bytes Desc: image001.gif URL: From Alan.Bateman at oracle.com Wed Sep 4 07:54:25 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 4 Sep 2019 08:54:25 +0100 Subject: RFR: 8229887: ZIP FS cannot replace an entry in a that was added via the STORED method In-Reply-To: References: Message-ID: <4ed1bb53-0813-b01a-e062-8b085eede368@oracle.com> On 04/09/2019 08:22, Langer, Christoph wrote: > > Hi Lance, > > thanks for your comments. I?ve requested the patches for jdk13u and > jdk11u then. By default they?d reach the Jan 2020 update release, so > they?ll get some time to bake in there. Actually, since this patch > fixes a regression that has been introduced just recently, I could > imagine that the fix would even be a candidate for the October > patches. It looks quite obvious and I don?t think that there?s a huge > performance risk. But I don?t want to take this decision on my own ?? > > There has been significant churn in the zipfs implementation in recent releases. Most of the changes came with regression tests but I'm concerned that we still don't have enough tests to be confident changes this code. Time stamps and zip64 are two areas where we often get bitten. I think we need to figure out how to do interop tests with other zip tools too. Improved tests would help with the confidence when changing this code and also help when there are requests for back ports. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From vkempik at azul.com Wed Sep 4 12:07:21 2019 From: vkempik at azul.com (Vladimir Kempik) Date: Wed, 4 Sep 2019 12:07:21 +0000 Subject: RFR: 8229872: (fs) Increase buffer size used with getmntent In-Reply-To: References: <1DF90E8C-07FB-4809-A2AD-04D9D0F2FF0D@azul.com> <87ftlxtllz.fsf@oldenburg2.str.redhat.com> <943b19d2-4846-3552-ab3d-6aaa598ece9e@oracle.com> <87v9uts4bz.fsf@oldenburg2.str.redhat.com> <2A80DD4F-6D09-477F-920C-B070601FBA54@azul.com> <87lfvps392.fsf@oldenburg2.str.redhat.com> <0FB89DBB-566C-4E32-8131-C15FA659022D@azul.com> <8736hvoqa3.fsf@oldenburg2.str.redhat.com> <20BDB142-8E77-4886-9902-CB1DE5CC4930@azul.com> <503abeab-0aae-937a-5c4b-b022e5f10dd1@oracle.com> <87a7bzsyyh.fsf@oldenburg2.str.redhat.com> <0D734383-604F-414C-9F5D-27E5C617E04F@azul.com> <05113D4C-1258-4502-9D5F-D1BE4C4BA5ED@azul.com> <4840e25c-4794-22bb-bc62-d1103d1988a1@oracle.com> Message-ID: <11AAA5FB-BD27-4E20-B4D8-24CC9A99E017@azul.com> Hello Please review v5 of fix: http://cr.openjdk.java.net/~vkempik/8229872/webrev.05 diff vs v4: moved getlinelen and rewind in UnixNativeDispatcher.c right after fclose. changed getlinelen return type to jlong slightly improved the comment about getlinelen and updated comments formatting in native part. Thanks, Vladimir. 3 ????. 2019 ?., ? 22:23, Alan Bateman > ???????(?): On 03/09/2019 19:58, Vladimir Kempik wrote: Hello. Looks reasonable. Just one question If I pass NativeBuffers.getNativeBuffer to getmntent and getmntent will decide to call realloc on that buffer. Will such NativeBuffer then be pointing to freed memory? If such NativeBuffer object gets destructed, will we get double free error? Ah yes, you did mention the realloc in one of the earlier mails and that isn't going to work with NativeBuffer. In that case, let's go with that part of the patch and maybe a comment reminds the reader that it may realloc. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Wed Sep 4 14:24:47 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 4 Sep 2019 15:24:47 +0100 Subject: RFR: 8229872: (fs) Increase buffer size used with getmntent In-Reply-To: <11AAA5FB-BD27-4E20-B4D8-24CC9A99E017@azul.com> References: <1DF90E8C-07FB-4809-A2AD-04D9D0F2FF0D@azul.com> <87ftlxtllz.fsf@oldenburg2.str.redhat.com> <943b19d2-4846-3552-ab3d-6aaa598ece9e@oracle.com> <87v9uts4bz.fsf@oldenburg2.str.redhat.com> <2A80DD4F-6D09-477F-920C-B070601FBA54@azul.com> <87lfvps392.fsf@oldenburg2.str.redhat.com> <0FB89DBB-566C-4E32-8131-C15FA659022D@azul.com> <8736hvoqa3.fsf@oldenburg2.str.redhat.com> <20BDB142-8E77-4886-9902-CB1DE5CC4930@azul.com> <503abeab-0aae-937a-5c4b-b022e5f10dd1@oracle.com> <87a7bzsyyh.fsf@oldenburg2.str.redhat.com> <0D734383-604F-414C-9F5D-27E5C617E04F@azul.com> <05113D4C-1258-4502-9D5F-D1BE4C4BA5ED@azul.com> <4840e25c-4794-22bb-bc62-d1103d1988a1@oracle.com> <11AAA5FB-BD27-4E20-B4D8-24CC9A99E017@azul.com> Message-ID: On 04/09/2019 13:07, Vladimir Kempik wrote: > Hello > Please review v5 of fix: > http://cr.openjdk.java.net/~vkempik/8229872/webrev.05 > > diff vs v4: > moved getlinelen and rewind in UnixNativeDispatcher.c right after fclose. > changed getlinelen return type to jlong > slightly improved the comment about getlinelen and updated comments > formatting in native part. > LinuxNativeDispatcher.getmntent shouldn't free buf before it has copied the strings from the mntent structure as it could potentially access memory that is allocated for something else. It also needs to check the return from malloc and throw an exception if possible (you'll see other examples of this). The size returned by getline doesn't include the NUL terminator. Are you sure that this size is large enough for the buffer that you specify to getmntent_r to store the strings? I expect it is because the strings that are stuffed into the buffer are a subset of the items that on the entry. Do I have that right? Have you considered using fseek instead of rewind to avoid the uncertainty as to whether errno is set? -Alan From vkempik at azul.com Wed Sep 4 14:52:17 2019 From: vkempik at azul.com (Vladimir Kempik) Date: Wed, 4 Sep 2019 14:52:17 +0000 Subject: RFR: 8229872: (fs) Increase buffer size used with getmntent In-Reply-To: References: <1DF90E8C-07FB-4809-A2AD-04D9D0F2FF0D@azul.com> <87ftlxtllz.fsf@oldenburg2.str.redhat.com> <943b19d2-4846-3552-ab3d-6aaa598ece9e@oracle.com> <87v9uts4bz.fsf@oldenburg2.str.redhat.com> <2A80DD4F-6D09-477F-920C-B070601FBA54@azul.com> <87lfvps392.fsf@oldenburg2.str.redhat.com> <0FB89DBB-566C-4E32-8131-C15FA659022D@azul.com> <8736hvoqa3.fsf@oldenburg2.str.redhat.com> <20BDB142-8E77-4886-9902-CB1DE5CC4930@azul.com> <503abeab-0aae-937a-5c4b-b022e5f10dd1@oracle.com> <87a7bzsyyh.fsf@oldenburg2.str.redhat.com> <0D734383-604F-414C-9F5D-27E5C617E04F@azul.com> <05113D4C-1258-4502-9D5F-D1BE4C4BA5ED@azul.com> <4840e25c-4794-22bb-bc62-d1103d1988a1@oracle.com> <11AAA5FB-BD27-4E20-B4D8-24CC9A99E017@azul.com> Message-ID: Hello See comments: > 4 ????. 2019 ?., ? 17:24, Alan Bateman ???????(?): > > On 04/09/2019 13:07, Vladimir Kempik wrote: >> Hello >> Please review v5 of fix: http://cr.openjdk.java.net/~vkempik/8229872/webrev.05 >> >> diff vs v4: >> moved getlinelen and rewind in UnixNativeDispatcher.c right after fclose. >> changed getlinelen return type to jlong >> slightly improved the comment about getlinelen and updated comments formatting in native part. >> > LinuxNativeDispatcher.getmntent shouldn't free buf before it has copied the strings from the mntent structure as it could potentially access memory that is allocated for something else. It also needs to check the return from malloc and throw an exception if possible (you'll see other examples of this). I have looked at getmntent_r in libmusl, you are right. I will fix that. > > The size returned by getline doesn't include the NUL terminator. Are you sure that this size is large enough for the buffer that you specify to getmntent_r to store the strings? I expect it is because the strings that are stuffed into the buffer are a subset of the items that on the entry. Do I have that right? > Its no issue since newline character counted, and getmntent_r is looking for newline character. Every line in /proc/mounts ends with newline character. from man getline: getline() reads an entire line from stream, storing the address of the buffer containing the text into *lineptr. The buffer is null-termi? nated and includes the newline character, if one was found. > Have you considered using fseek instead of rewind to avoid the uncertainty as to whether errno is set? it seems fseek vs rewind&ferror is : with fseek we will know errno while with rewind&ferror we will know the error happened but no errno. do you thinks its better to introduce fseek (but how do I specify SEEK_SET in java then, some enum?) or just rewrite native part of rewind to actually use fseek? Thanks, Vladimir > > -Alan > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From fweimer at redhat.com Wed Sep 4 15:04:54 2019 From: fweimer at redhat.com (Florian Weimer) Date: Wed, 04 Sep 2019 17:04:54 +0200 Subject: RFR: 8229872: (fs) Increase buffer size used with getmntent In-Reply-To: (Alan Bateman's message of "Wed, 4 Sep 2019 15:24:47 +0100") References: <1DF90E8C-07FB-4809-A2AD-04D9D0F2FF0D@azul.com> <87ftlxtllz.fsf@oldenburg2.str.redhat.com> <943b19d2-4846-3552-ab3d-6aaa598ece9e@oracle.com> <87v9uts4bz.fsf@oldenburg2.str.redhat.com> <2A80DD4F-6D09-477F-920C-B070601FBA54@azul.com> <87lfvps392.fsf@oldenburg2.str.redhat.com> <0FB89DBB-566C-4E32-8131-C15FA659022D@azul.com> <8736hvoqa3.fsf@oldenburg2.str.redhat.com> <20BDB142-8E77-4886-9902-CB1DE5CC4930@azul.com> <503abeab-0aae-937a-5c4b-b022e5f10dd1@oracle.com> <87a7bzsyyh.fsf@oldenburg2.str.redhat.com> <0D734383-604F-414C-9F5D-27E5C617E04F@azul.com> <05113D4C-1258-4502-9D5F-D1BE4C4BA5ED@azul.com> <4840e25c-4794-22bb-bc62-d1103d1988a1@oracle.com> <11AAA5FB-BD27-4E20-B4D8-24CC9A99E017@azul.com> Message-ID: <87blw0nlux.fsf@oldenburg2.str.redhat.com> * Alan Bateman: > Have you considered using fseek instead of rewind to avoid the > uncertainty as to whether errno is set? POSIX requires that rewind sets errno on failure, so I'm not sure if this is necessary. At least with rewind, you don't have to worry if you need to call fseek or fseeko or fseeko64. Thanks, Florian From martinrb at google.com Wed Sep 4 15:27:45 2019 From: martinrb at google.com (Martin Buchholz) Date: Wed, 4 Sep 2019 08:27:45 -0700 Subject: RFR: 8229887: ZIP FS cannot replace an entry in a that was added via the STORED method In-Reply-To: <4ed1bb53-0813-b01a-e062-8b085eede368@oracle.com> References: <4ed1bb53-0813-b01a-e062-8b085eede368@oracle.com> Message-ID: On Wed, Sep 4, 2019 at 12:54 AM Alan Bateman wrote: > On 04/09/2019 08:22, Langer, Christoph wrote: > > Hi Lance, > > > > thanks for your comments. I?ve requested the patches for jdk13u and jdk11u > then. By default they?d reach the Jan 2020 update release, so they?ll get > some time to bake in there. Actually, since this patch fixes a regression > that has been introduced just recently, I could imagine that the fix would > even be a candidate for the October patches. It looks quite obvious and I > don?t think that there?s a huge performance risk. But I don?t want to take > this decision on my own ?? > > There has been significant churn in the zipfs implementation in recent > releases. Most of the changes came with regression tests but I'm concerned > that we still don't have enough tests to be confident changes this code. > Time stamps and zip64 are two areas where we often get bitten. I think we > need to figure out how to do interop tests with other zip tools too. > Improved tests would help with the confidence when changing this code and > also help when there are requests for back ports. > I also tend to be cautious about backports, and I agree that zipfs testing should have been improved, but 8229887 is a serious regression - creating corrupted zip files - that should be backported ASAP. -------------- next part -------------- An HTML attachment was scrubbed... URL: From vkempik at azul.com Wed Sep 4 15:35:45 2019 From: vkempik at azul.com (Vladimir Kempik) Date: Wed, 4 Sep 2019 15:35:45 +0000 Subject: RFR: 8229872: (fs) Increase buffer size used with getmntent In-Reply-To: <87blw0nlux.fsf@oldenburg2.str.redhat.com> References: <1DF90E8C-07FB-4809-A2AD-04D9D0F2FF0D@azul.com> <87ftlxtllz.fsf@oldenburg2.str.redhat.com> <943b19d2-4846-3552-ab3d-6aaa598ece9e@oracle.com> <87v9uts4bz.fsf@oldenburg2.str.redhat.com> <2A80DD4F-6D09-477F-920C-B070601FBA54@azul.com> <87lfvps392.fsf@oldenburg2.str.redhat.com> <0FB89DBB-566C-4E32-8131-C15FA659022D@azul.com> <8736hvoqa3.fsf@oldenburg2.str.redhat.com> <20BDB142-8E77-4886-9902-CB1DE5CC4930@azul.com> <503abeab-0aae-937a-5c4b-b022e5f10dd1@oracle.com> <87a7bzsyyh.fsf@oldenburg2.str.redhat.com> <0D734383-604F-414C-9F5D-27E5C617E04F@azul.com> <05113D4C-1258-4502-9D5F-D1BE4C4BA5ED@azul.com> <4840e25c-4794-22bb-bc62-d1103d1988a1@oracle.com> <11AAA5FB-BD27-4E20-B4D8-24CC9A99E017@azul.com> <87blw0nlux.fsf@oldenburg2.str.redhat.com> Message-ID: <0EE06BE6-90C7-406F-B82D-D639B68ED972@azul.com> Hello Please review v6 of the patch http://cr.openjdk.java.net/~vkempik/8229872/webrev.06/ diff vs v5: - setting errno = 0 before calling rewind and reading errno in case of error - getmntent_r now checks for malloc result and frees that buffer only when it becomes unneeded. Thanks, Vladimir > 4 ????. 2019 ?., ? 18:04, Florian Weimer ???????(?): > > * Alan Bateman: > >> Have you considered using fseek instead of rewind to avoid the >> uncertainty as to whether errno is set? > > POSIX requires that rewind sets errno on failure, so I'm not sure if > this is necessary. At least with rewind, you don't have to worry if you > need to call fseek or fseeko or fseeko64. > > Thanks, > Florian -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From Alan.Bateman at oracle.com Wed Sep 4 15:38:06 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 4 Sep 2019 16:38:06 +0100 Subject: RFR: 8229872: (fs) Increase buffer size used with getmntent In-Reply-To: References: <1DF90E8C-07FB-4809-A2AD-04D9D0F2FF0D@azul.com> <87v9uts4bz.fsf@oldenburg2.str.redhat.com> <2A80DD4F-6D09-477F-920C-B070601FBA54@azul.com> <87lfvps392.fsf@oldenburg2.str.redhat.com> <0FB89DBB-566C-4E32-8131-C15FA659022D@azul.com> <8736hvoqa3.fsf@oldenburg2.str.redhat.com> <20BDB142-8E77-4886-9902-CB1DE5CC4930@azul.com> <503abeab-0aae-937a-5c4b-b022e5f10dd1@oracle.com> <87a7bzsyyh.fsf@oldenburg2.str.redhat.com> <0D734383-604F-414C-9F5D-27E5C617E04F@azul.com> <05113D4C-1258-4502-9D5F-D1BE4C4BA5ED@azul.com> <4840e25c-4794-22bb-bc62-d1103d1988a1@oracle.com> <11AAA5FB-BD27-4E20-B4D8-24CC9A99E017@azul.com> Message-ID: <179c534c-9a83-4a14-7023-fe332bdcdd8a@oracle.com> On 04/09/2019 15:52, Vladimir Kempik wrote: > : > Its no issue since newline character counted, and getmntent_r is looking for newline character. Every line in /proc/mounts ends with newline character. > from man getline: > getline() reads an entire line from stream, storing the address of the > buffer containing the text into *lineptr. The buffer is null-termi? > nated and includes the newline character, if one was found. It's the return value that I was wondering about as that it's the number of bytes written excluding the NUL. > >> Have you considered using fseek instead of rewind to avoid the uncertainty as to whether errno is set? > it seems fseek vs rewind&ferror is : with fseek we will know errno while with rewind&ferror we will know the error happened but no errno. > > do you thinks its better to introduce fseek (but how do I specify SEEK_SET in java then, some enum?) or just rewrite native part of rewind to actually use fseek? > My only reason for asking is that you've got a FIXME in the comment to say that rewind doesn't specify how it reports errors. I checked the man page on macOS and it does. I also see Florian's mails to say that we don't need to worry about it. -Alan From vkempik at azul.com Wed Sep 4 15:47:14 2019 From: vkempik at azul.com (Vladimir Kempik) Date: Wed, 4 Sep 2019 15:47:14 +0000 Subject: RFR: 8229872: (fs) Increase buffer size used with getmntent In-Reply-To: <179c534c-9a83-4a14-7023-fe332bdcdd8a@oracle.com> References: <1DF90E8C-07FB-4809-A2AD-04D9D0F2FF0D@azul.com> <87v9uts4bz.fsf@oldenburg2.str.redhat.com> <2A80DD4F-6D09-477F-920C-B070601FBA54@azul.com> <87lfvps392.fsf@oldenburg2.str.redhat.com> <0FB89DBB-566C-4E32-8131-C15FA659022D@azul.com> <8736hvoqa3.fsf@oldenburg2.str.redhat.com> <20BDB142-8E77-4886-9902-CB1DE5CC4930@azul.com> <503abeab-0aae-937a-5c4b-b022e5f10dd1@oracle.com> <87a7bzsyyh.fsf@oldenburg2.str.redhat.com> <0D734383-604F-414C-9F5D-27E5C617E04F@azul.com> <05113D4C-1258-4502-9D5F-D1BE4C4BA5ED@azul.com> <4840e25c-4794-22bb-bc62-d1103d1988a1@oracle.com> <11AAA5FB-BD27-4E20-B4D8-24CC9A99E017@azul.com> <179c534c-9a83-4a14-7023-fe332bdcdd8a@oracle.com> Message-ID: I see. I have dumped both lineSize and res within getlinelen, here is result: linesize = 120, res = 53 linesize = 120, res = 52 linesize = 120, res = 83 linesize = 120, res = 81 linesize = 120, res = 69 linesize = 120, res = 82 linesize = 120, res = 79 linesize = 120, res = 41 linesize = 120, res = 69 linesize = 120, res = 63 linesize = 240, res = 141 linesize = 120, res = 65 linesize = 120, res = 75 linesize = 120, res = 81 linesize = 120, res = 81 linesize = 120, res = 99 linesize = 120, res = 77 linesize = 120, res = 75 linesize = 120, res = 89 linesize = 120, res = 87 linesize = 120, res = 79 linesize = 120, res = 81 linesize = 120, res = 79 linesize = 240, res = 125 linesize = 120, res = 57 linesize = 120, res = 50 linesize = 120, res = 42 linesize = 120, res = 63 linesize = 120, res = 53 linesize = 120, res = 37 linesize = 120, res = 96 linesize = 120, res = 103 linesize = 120, res = 105 linesize = 1318, res = 1317 linesize = 240, res = 154 linesize = 120, res = 48 linesize = 120, res = -1 What is better to return, lineSize or res+1 ? Thanks, Vladimir P.S. currently returning just res seems to works fine. > 4 ????. 2019 ?., ? 18:38, Alan Bateman ???????(?): > > > > On 04/09/2019 15:52, Vladimir Kempik wrote: >> : >> Its no issue since newline character counted, and getmntent_r is looking for newline character. Every line in /proc/mounts ends with newline character. >> from man getline: >> getline() reads an entire line from stream, storing the address of the >> buffer containing the text into *lineptr. The buffer is null-termi? >> nated and includes the newline character, if one was found. > It's the return value that I was wondering about as that it's the number of bytes written excluding the NUL. > >> >>> Have you considered using fseek instead of rewind to avoid the uncertainty as to whether errno is set? >> it seems fseek vs rewind&ferror is : with fseek we will know errno while with rewind&ferror we will know the error happened but no errno. >> >> do you thinks its better to introduce fseek (but how do I specify SEEK_SET in java then, some enum?) or just rewrite native part of rewind to actually use fseek? >> > My only reason for asking is that you've got a FIXME in the comment to say that rewind doesn't specify how it reports errors. I checked the man page on macOS and it does. I also see Florian's mails to say that we don't need to worry about it. > > -Alan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From vkempik at azul.com Wed Sep 4 15:56:01 2019 From: vkempik at azul.com (Vladimir Kempik) Date: Wed, 4 Sep 2019 15:56:01 +0000 Subject: RFR: 8229872: (fs) Increase buffer size used with getmntent In-Reply-To: References: <1DF90E8C-07FB-4809-A2AD-04D9D0F2FF0D@azul.com> <87v9uts4bz.fsf@oldenburg2.str.redhat.com> <2A80DD4F-6D09-477F-920C-B070601FBA54@azul.com> <87lfvps392.fsf@oldenburg2.str.redhat.com> <0FB89DBB-566C-4E32-8131-C15FA659022D@azul.com> <8736hvoqa3.fsf@oldenburg2.str.redhat.com> <20BDB142-8E77-4886-9902-CB1DE5CC4930@azul.com> <503abeab-0aae-937a-5c4b-b022e5f10dd1@oracle.com> <87a7bzsyyh.fsf@oldenburg2.str.redhat.com> <0D734383-604F-414C-9F5D-27E5C617E04F@azul.com> <05113D4C-1258-4502-9D5F-D1BE4C4BA5ED@azul.com> <4840e25c-4794-22bb-bc62-d1103d1988a1@oracle.com> <11AAA5FB-BD27-4E20-B4D8-24CC9A99E017@azul.com> <179c534c-9a83-4a14-7023-fe332bdcdd8a@oracle.com> Message-ID: Hello After thinking about it, I think it?s better to leave getlinelen as is, and just increase maxLineSize by one in getMountEntries. here is webrev: http://cr.openjdk.java.net/~vkempik/8229872/webrev.07/ THanks, Vladimir 4 ????. 2019 ?., ? 18:47, Vladimir Kempik > ???????(?): I see. I have dumped both lineSize and res within getlinelen, here is result: linesize = 120, res = 53 linesize = 120, res = 52 linesize = 120, res = 83 linesize = 120, res = 81 linesize = 120, res = 69 linesize = 120, res = 82 linesize = 120, res = 79 linesize = 120, res = 41 linesize = 120, res = 69 linesize = 120, res = 63 linesize = 240, res = 141 linesize = 120, res = 65 linesize = 120, res = 75 linesize = 120, res = 81 linesize = 120, res = 81 linesize = 120, res = 99 linesize = 120, res = 77 linesize = 120, res = 75 linesize = 120, res = 89 linesize = 120, res = 87 linesize = 120, res = 79 linesize = 120, res = 81 linesize = 120, res = 79 linesize = 240, res = 125 linesize = 120, res = 57 linesize = 120, res = 50 linesize = 120, res = 42 linesize = 120, res = 63 linesize = 120, res = 53 linesize = 120, res = 37 linesize = 120, res = 96 linesize = 120, res = 103 linesize = 120, res = 105 linesize = 1318, res = 1317 linesize = 240, res = 154 linesize = 120, res = 48 linesize = 120, res = -1 What is better to return, lineSize or res+1 ? Thanks, Vladimir P.S. currently returning just res seems to works fine. 4 ????. 2019 ?., ? 18:38, Alan Bateman > ???????(?): On 04/09/2019 15:52, Vladimir Kempik wrote: : Its no issue since newline character counted, and getmntent_r is looking for newline character. Every line in /proc/mounts ends with newline character. from man getline: getline() reads an entire line from stream, storing the address of the buffer containing the text into *lineptr. The buffer is null-termi? nated and includes the newline character, if one was found. It's the return value that I was wondering about as that it's the number of bytes written excluding the NUL. Have you considered using fseek instead of rewind to avoid the uncertainty as to whether errno is set? it seems fseek vs rewind&ferror is : with fseek we will know errno while with rewind&ferror we will know the error happened but no errno. do you thinks its better to introduce fseek (but how do I specify SEEK_SET in java then, some enum?) or just rewrite native part of rewind to actually use fseek? My only reason for asking is that you've got a FIXME in the comment to say that rewind doesn't specify how it reports errors. I checked the man page on macOS and it does. I also see Florian's mails to say that we don't need to worry about it. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From shade at redhat.com Wed Sep 4 16:04:40 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 4 Sep 2019 18:04:40 +0200 Subject: RFR: 8229887: ZIP FS cannot replace an entry in a that was added via the STORED method In-Reply-To: References: <4ed1bb53-0813-b01a-e062-8b085eede368@oracle.com> Message-ID: <92809bc4-36b2-2344-4f28-243676645d85@redhat.com> On 9/4/19 5:27 PM, Martin Buchholz wrote: > I also tend to be cautious about backports, and I agree that zipfs testing should have been > improved, but ?8229887 is a serious regression - creating corrupted zip files - that should be > backported ASAP. I agree with Martin here. Christoph, can you talk with other 11u people to see if it makes sense for 11u critical patch? -- Thanks, -Aleksey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From fweimer at redhat.com Wed Sep 4 16:15:55 2019 From: fweimer at redhat.com (Florian Weimer) Date: Wed, 04 Sep 2019 18:15:55 +0200 Subject: RFR: 8229872: (fs) Increase buffer size used with getmntent In-Reply-To: (Vladimir Kempik's message of "Wed, 4 Sep 2019 15:56:01 +0000") References: <1DF90E8C-07FB-4809-A2AD-04D9D0F2FF0D@azul.com> <87lfvps392.fsf@oldenburg2.str.redhat.com> <0FB89DBB-566C-4E32-8131-C15FA659022D@azul.com> <8736hvoqa3.fsf@oldenburg2.str.redhat.com> <20BDB142-8E77-4886-9902-CB1DE5CC4930@azul.com> <503abeab-0aae-937a-5c4b-b022e5f10dd1@oracle.com> <87a7bzsyyh.fsf@oldenburg2.str.redhat.com> <0D734383-604F-414C-9F5D-27E5C617E04F@azul.com> <05113D4C-1258-4502-9D5F-D1BE4C4BA5ED@azul.com> <4840e25c-4794-22bb-bc62-d1103d1988a1@oracle.com> <11AAA5FB-BD27-4E20-B4D8-24CC9A99E017@azul.com> <179c534c-9a83-4a14-7023-fe332bdcdd8a@oracle.com> Message-ID: <8736hcnikk.fsf@oldenburg2.str.redhat.com> * Vladimir Kempik: > After thinking about it, I think it?s better to leave getlinelen as is, and just increase maxLineSize by one in getMountEntries. > > here is webrev: http://cr.openjdk.java.net/~vkempik/8229872/webrev.07/ Buffer sizes should be size_t, not int (in Java_sun_nio_fs_LinuxNativeDispatcher_getmntent). The error handling in Java_sun_nio_fs_UnixNativeDispatcher_getlinelen does not look portable to me. Some versions of getline return -1 on EOF. Something like int saved_errno; ssize_t res = getline(&lineBuffer, &lineSize, fp); saved_errno = errno; free(lineBuffer); if (feof(fp)) return 0; if (res == -1) throwUnixException(env, saved_errno); return res; should work. Thanks, Florian From brian.burkhalter at oracle.com Wed Sep 4 18:40:41 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 4 Sep 2019 11:40:41 -0700 Subject: 8229280: Test failures on several linux hosts after JDK-8181493 In-Reply-To: References: <2D854054-B445-406B-8777-4D1DA2F95137@oracle.com> <97F6E4AD-3802-4A2C-8043-3158DA323B37@oracle.com> <88BB88A0-AE86-478F-8B9C-EA45F4B7A8C1@oracle.com> <018859AB-83DD-4704-A92A-8FFB50B35970@oracle.com> <7b4c2bd4-4e3d-70f0-9d8b-b0d24ae038a0@oracle.com> <8DE2D4E9-E312-4E73-A692-DE35141BFC2A@oracle.com> <638E1D14-E6F7-4BD1-97F2-1579F437D930@oracle.com> Message-ID: <090F0BD2-244B-4B31-8DA8-E459ADE2F06C@oracle.com> > On Sep 1, 2019, at 1:16 AM, Alan Bateman wrote: > > On 29/08/2019 01:56, Brian Burkhalter wrote: >> >> Done [1]. > The test description needs `@modules java.base/sun.nio.fs:+open` to open the package to the test. That should allow L42-50 to be cleaned up. With the @modules tag as above compilation fails: // Check whether futimens() system call is supported Method futimensSupported = sun.nio.fs.UnixNativeDispatcher.class.getDeclaredMethod("futimensSupported"); futimensSupported.setAccessible(true); if (!(boolean)futimensSupported.invoke(null)) { System.err.println ("futimens() system call not supported; skipping test"); return; } java/nio/file/attribute/BasicFileAttributeView/SetTimesNanos.java:45: error: UnixNativeDispatcher is not public in sun.nio.fs; cannot be accessed from outside package sun.nio.fs.UnixNativeDispatcher.class.getDeclaredMethod("futimensSupported"); ^ 1 error >> Note however that futimens() can be supported without it actually being able to set the timestamps to nanosecond precision, e.g., for HFS file systems on macOS. Therefore the test will still pass if the actual and expected values are not equal due to truncation of a multiple of three digits of precision. > Is there any way that we could use the FileStore::type to target this test to specify file systems that are known to support nanosecond precision? Sure. These types at least would work: apfs, ext4, xfs, zfs. That would get rid of ugly truncation checking. Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Wed Sep 4 18:44:57 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 4 Sep 2019 19:44:57 +0100 Subject: 8229280: Test failures on several linux hosts after JDK-8181493 In-Reply-To: <090F0BD2-244B-4B31-8DA8-E459ADE2F06C@oracle.com> References: <2D854054-B445-406B-8777-4D1DA2F95137@oracle.com> <97F6E4AD-3802-4A2C-8043-3158DA323B37@oracle.com> <88BB88A0-AE86-478F-8B9C-EA45F4B7A8C1@oracle.com> <018859AB-83DD-4704-A92A-8FFB50B35970@oracle.com> <7b4c2bd4-4e3d-70f0-9d8b-b0d24ae038a0@oracle.com> <8DE2D4E9-E312-4E73-A692-DE35141BFC2A@oracle.com> <638E1D14-E6F7-4BD1-97F2-1579F437D930@oracle.com> <090F0BD2-244B-4B31-8DA8-E459ADE2F06C@oracle.com> Message-ID: On 04/09/2019 19:40, Brian Burkhalter wrote: > : > > With the @modules tag as above compilation fails: > > ? ? ? ??// Check whether futimens() system call is supported > ? ? ? ? Method futimensSupported = > sun.nio.fs.UnixNativeDispatcher.class.getDeclaredMethod("futimensSupported"); > ? ? ? ? futimensSupported.setAccessible(true); > ? ? ? ? if (!(boolean)futimensSupported.invoke(null)) { > ? ? ? ? ? ? System.err.println > ? ? ? ? ? ? ? ? ("futimens() system call not supported; skipping test"); > ? ? ? ? ? ? return; > ? ? ? ? } > > java/nio/file/attribute/BasicFileAttributeView/SetTimesNanos.java:45: > error: UnixNativeDispatcher is not public in sun.nio.fs; cannot be > accessed from outside package > sun.nio.fs.UnixNativeDispatcher.class.getDeclaredMethod("futimensSupported"); > ? ? ? ? ? ? ? ? ? ? ? ^ > 1 error It looks like you've changed it from Class.forName to a static reference. I didn't suggest that, instead I was pointing out that you need the +open to ensure that sun.nio.fs is open to the test for deep reflective purposes. > > Sure. These types at least would work: apfs, ext4, xfs, zfs. That > would get rid of ugly truncation checking. > That would be good as it would limit the test to scenarios where it is expected to pass. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Wed Sep 4 18:46:15 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 4 Sep 2019 11:46:15 -0700 Subject: 8229280: Test failures on several linux hosts after JDK-8181493 In-Reply-To: References: <2D854054-B445-406B-8777-4D1DA2F95137@oracle.com> <97F6E4AD-3802-4A2C-8043-3158DA323B37@oracle.com> <88BB88A0-AE86-478F-8B9C-EA45F4B7A8C1@oracle.com> <018859AB-83DD-4704-A92A-8FFB50B35970@oracle.com> <7b4c2bd4-4e3d-70f0-9d8b-b0d24ae038a0@oracle.com> <8DE2D4E9-E312-4E73-A692-DE35141BFC2A@oracle.com> <638E1D14-E6F7-4BD1-97F2-1579F437D930@oracle.com> <090F0BD2-244B-4B31-8DA8-E459ADE2F06C@oracle.com> Message-ID: <6AA39403-222D-4E45-950F-465AAA815FBE@oracle.com> > On Sep 4, 2019, at 11:44 AM, Alan Bateman wrote: > >> java/nio/file/attribute/BasicFileAttributeView/SetTimesNanos.java:45: error: UnixNativeDispatcher is not public in sun.nio.fs; cannot be accessed from outside package >> sun.nio.fs.UnixNativeDispatcher.class.getDeclaredMethod("futimensSupported"); >> ^ >> 1 error > It looks like you've changed it from Class.forName to a static reference. I didn't suggest that, instead I was pointing out that you need the +open to ensure that sun.nio.fs is open to the test for deep reflective purposes. That?s right. The test however worked with and without the +open. >> >> Sure. These types at least would work: apfs, ext4, xfs, zfs. That would get rid of ugly truncation checking. >> > That would be good as it would limit the test to scenarios where it is expected to pass. OK Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Wed Sep 4 19:09:34 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 4 Sep 2019 12:09:34 -0700 Subject: 8229280: Test failures on several linux hosts after JDK-8181493 In-Reply-To: <6AA39403-222D-4E45-950F-465AAA815FBE@oracle.com> References: <2D854054-B445-406B-8777-4D1DA2F95137@oracle.com> <97F6E4AD-3802-4A2C-8043-3158DA323B37@oracle.com> <88BB88A0-AE86-478F-8B9C-EA45F4B7A8C1@oracle.com> <018859AB-83DD-4704-A92A-8FFB50B35970@oracle.com> <7b4c2bd4-4e3d-70f0-9d8b-b0d24ae038a0@oracle.com> <8DE2D4E9-E312-4E73-A692-DE35141BFC2A@oracle.com> <638E1D14-E6F7-4BD1-97F2-1579F437D930@oracle.com> <090F0BD2-244B-4B31-8DA8-E459ADE2F06C@oracle.com> <6AA39403-222D-4E45-950F-465AAA815FBE@oracle.com> Message-ID: > On Sep 4, 2019, at 11:46 AM, Brian Burkhalter wrote: > >> On Sep 4, 2019, at 11:44 AM, Alan Bateman > wrote: >> >>> java/nio/file/attribute/BasicFileAttributeView/SetTimesNanos.java:45: error: UnixNativeDispatcher is not public in sun.nio.fs; cannot be accessed from outside package >>> sun.nio.fs.UnixNativeDispatcher.class.getDeclaredMethod("futimensSupported"); >>> ^ >>> 1 error >> It looks like you've changed it from Class.forName to a static reference. I didn't suggest that, instead I was pointing out that you need the +open to ensure that sun.nio.fs is open to the test for deep reflective purposes. > > That?s right. The test however worked with and without the +open. > >>> >>> Sure. These types at least would work: apfs, ext4, xfs, zfs. That would get rid of ugly truncation checking. >>> >> That would be good as it would limit the test to scenarios where it is expected to pass. > > OK Here is an updated version which should address the foregoing problems: http://cr.openjdk.java.net/~bpb/8229280/webrev.02/ Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Wed Sep 4 19:24:40 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 4 Sep 2019 20:24:40 +0100 Subject: 8229280: Test failures on several linux hosts after JDK-8181493 In-Reply-To: References: <2D854054-B445-406B-8777-4D1DA2F95137@oracle.com> <97F6E4AD-3802-4A2C-8043-3158DA323B37@oracle.com> <88BB88A0-AE86-478F-8B9C-EA45F4B7A8C1@oracle.com> <018859AB-83DD-4704-A92A-8FFB50B35970@oracle.com> <7b4c2bd4-4e3d-70f0-9d8b-b0d24ae038a0@oracle.com> <8DE2D4E9-E312-4E73-A692-DE35141BFC2A@oracle.com> <638E1D14-E6F7-4BD1-97F2-1579F437D930@oracle.com> <090F0BD2-244B-4B31-8DA8-E459ADE2F06C@oracle.com> <6AA39403-222D-4E45-950F-465AAA815FBE@oracle.com> Message-ID: <6d6f374a-17a1-e40a-ea68-d282c0bf1c50@oracle.com> On 04/09/2019 20:09, Brian Burkhalter wrote: > > Here is an updated version which should address the foregoing problems: > > http://cr.openjdk.java.net/~bpb/8229280/webrev.02/ > Good, this is much easier to maintain. A minor nit is that the testedTypes should be a Set to avoid the raw type warning. Also if you allow the lines to be just a bit longer then it would avoid the awkward line breaks at L46, 48, 52, and 65. -Alan From brian.burkhalter at oracle.com Wed Sep 4 20:05:22 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 4 Sep 2019 13:05:22 -0700 Subject: 8229280: Test failures on several linux hosts after JDK-8181493 In-Reply-To: <6d6f374a-17a1-e40a-ea68-d282c0bf1c50@oracle.com> References: <2D854054-B445-406B-8777-4D1DA2F95137@oracle.com> <97F6E4AD-3802-4A2C-8043-3158DA323B37@oracle.com> <88BB88A0-AE86-478F-8B9C-EA45F4B7A8C1@oracle.com> <018859AB-83DD-4704-A92A-8FFB50B35970@oracle.com> <7b4c2bd4-4e3d-70f0-9d8b-b0d24ae038a0@oracle.com> <8DE2D4E9-E312-4E73-A692-DE35141BFC2A@oracle.com> <638E1D14-E6F7-4BD1-97F2-1579F437D930@oracle.com> <090F0BD2-244B-4B31-8DA8-E459ADE2F06C@oracle.com> <6AA39403-222D-4E45-950F-465AAA815FBE@oracle.com> <6d6f374a-17a1-e40a-ea68-d282c0bf1c50@oracle.com> Message-ID: > On Sep 4, 2019, at 12:24 PM, Alan Bateman wrote: > > On 04/09/2019 20:09, Brian Burkhalter wrote: >> >> Here is an updated version which should address the foregoing problems: >> >> http://cr.openjdk.java.net/~bpb/8229280/webrev.02/ >> > Good, this is much easier to maintain. > > A minor nit is that the testedTypes should be a Set to avoid the raw type warning. Also if you allow the lines to be just a bit longer then it would avoid the awkward line breaks at L46, 48, 52, and 65. I have applied the foregoing changes at http://cr.openjdk.java.net/~bpb/8229280/webrev.03/. Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Thu Sep 5 07:03:13 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 5 Sep 2019 08:03:13 +0100 Subject: 8229280: Test failures on several linux hosts after JDK-8181493 In-Reply-To: References: <2D854054-B445-406B-8777-4D1DA2F95137@oracle.com> <88BB88A0-AE86-478F-8B9C-EA45F4B7A8C1@oracle.com> <018859AB-83DD-4704-A92A-8FFB50B35970@oracle.com> <7b4c2bd4-4e3d-70f0-9d8b-b0d24ae038a0@oracle.com> <8DE2D4E9-E312-4E73-A692-DE35141BFC2A@oracle.com> <638E1D14-E6F7-4BD1-97F2-1579F437D930@oracle.com> <090F0BD2-244B-4B31-8DA8-E459ADE2F06C@oracle.com> <6AA39403-222D-4E45-950F-465AAA815FBE@oracle.com> <6d6f374a-17a1-e40a-ea68-d282c0bf1c50@oracle.com> Message-ID: <0217d9fd-9285-68f6-d6dc-61d03a49b499@oracle.com> On 04/09/2019 21:05, Brian Burkhalter wrote: > : > > I have applied the foregoing changes at > http://cr.openjdk.java.net/~bpb/8229280/webrev.03/. > This looks good. -Alan From Alan.Bateman at oracle.com Thu Sep 5 08:52:20 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 5 Sep 2019 09:52:20 +0100 Subject: RFR: 8229872: (fs) Increase buffer size used with getmntent In-Reply-To: References: <1DF90E8C-07FB-4809-A2AD-04D9D0F2FF0D@azul.com> <0FB89DBB-566C-4E32-8131-C15FA659022D@azul.com> <8736hvoqa3.fsf@oldenburg2.str.redhat.com> <20BDB142-8E77-4886-9902-CB1DE5CC4930@azul.com> <503abeab-0aae-937a-5c4b-b022e5f10dd1@oracle.com> <87a7bzsyyh.fsf@oldenburg2.str.redhat.com> <0D734383-604F-414C-9F5D-27E5C617E04F@azul.com> <05113D4C-1258-4502-9D5F-D1BE4C4BA5ED@azul.com> <4840e25c-4794-22bb-bc62-d1103d1988a1@oracle.com> <11AAA5FB-BD27-4E20-B4D8-24CC9A99E017@azul.com> <179c534c-9a83-4a14-7023-fe332bdcdd8a@oracle.com> Message-ID: <24d7ea75-53d0-bd2e-0199-d2d0457a071d@oracle.com> On 04/09/2019 16:56, Vladimir Kempik wrote: > Hello > After thinking about it, I think it?s better to leave getlinelen as > is, and just increase maxLineSize by one in getMountEntries. > > here is webrev: http://cr.openjdk.java.net/~vkempik/8229872/webrev.07/ > UnixNativeDispatcher.rewind - the comment L413-419 needs cleanup, I think should be one line or just removed. UnixNativeDispatcher.getlinelen - the function description is confusing. I think it should be removed or replaced with something simple that explains that it returns the line length (without the NUL terminator) or -1 when at EOF. I see Florian's mail that -1 can be EOF or an error and I agree this needs to be cleaned up. LinuxNativeDispatcher.getmntent - the parameter to the native method should be bufLen to match the libc function that it calls. Also I think we should try to keep the formatting/style consistent with the existing code, meaning the NULL checks should be "if (bytes == NULL) {" rather than putting the open brace on a new line. LinuxFileSystem.getMountEntries. - maxLineSize++ in the finally block is confusing. I think it would be cleaner to have the following after the finally block: ? long bufLen = maxLineLen + 1; and then call getmntent with bugLen. This will avoid misleading further maintainers into thinking that maxLineLen is the maxium line length. At L88 you need a line break to put the statement on the next line (to keep it consistent with the existing code). -Alan. -------------- next part -------------- An HTML attachment was scrubbed... URL: From christoph.langer at sap.com Thu Sep 5 10:26:53 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 5 Sep 2019 10:26:53 +0000 Subject: [11u] RFR: 8229887: (zipfs) zip file corruption when replacing an existing STORED entry Message-ID: Hi, may I please get a review for the backport of this item to jdk11 updates: Bug: https://bugs.openjdk.java.net/browse/JDK-8229887 Original Change: https://hg.openjdk.java.net/jdk/jdk/rev/abf6ee4c477c Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8229887.11u.0/ The original patch applies cleanly but the method java.nio.file.FileSystems::newFileSystem(Path path) that is used in the test was only introduced in JDK13. So I have to fallback to java.nio.file.FileSystems:: newFileSystem(Path path, ClassLoader loader) at these places (lines 123, 163 and 195 of UpdateEntryTest). With this modification, the test passes. Thanks Christoph -------------- next part -------------- An HTML attachment was scrubbed... URL: From christoph.langer at sap.com Thu Sep 5 10:42:56 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 5 Sep 2019 10:42:56 +0000 Subject: RFR: 8229887: ZIP FS cannot replace an entry in a that was added via the STORED method In-Reply-To: References: <4ed1bb53-0813-b01a-e062-8b085eede368@oracle.com> Message-ID: Hi Martin, I agree to get this one backported soon. I can see that the change that introduced this regression (JDK-8222532) was only backported to OpenJDK 11.0.4 but not to Oracle?s 11.0.4. So we should fix it immediately and I?ve requested to target this to 11.0.5. Thanks Christoph From: Martin Buchholz Sent: Mittwoch, 4. September 2019 17:28 To: Alan Bateman Cc: Langer, Christoph ; Lance Andersen ; nio-dev Subject: Re: RFR: 8229887: ZIP FS cannot replace an entry in a that was added via the STORED method On Wed, Sep 4, 2019 at 12:54 AM Alan Bateman > wrote: On 04/09/2019 08:22, Langer, Christoph wrote: Hi Lance, thanks for your comments. I?ve requested the patches for jdk13u and jdk11u then. By default they?d reach the Jan 2020 update release, so they?ll get some time to bake in there. Actually, since this patch fixes a regression that has been introduced just recently, I could imagine that the fix would even be a candidate for the October patches. It looks quite obvious and I don?t think that there?s a huge performance risk. But I don?t want to take this decision on my own ?? There has been significant churn in the zipfs implementation in recent releases. Most of the changes came with regression tests but I'm concerned that we still don't have enough tests to be confident changes this code. Time stamps and zip64 are two areas where we often get bitten. I think we need to figure out how to do interop tests with other zip tools too. Improved tests would help with the confidence when changing this code and also help when there are requests for back ports. I also tend to be cautious about backports, and I agree that zipfs testing should have been improved, but 8229887 is a serious regression - creating corrupted zip files - that should be backported ASAP. -------------- next part -------------- An HTML attachment was scrubbed... URL: From christoph.langer at sap.com Fri Sep 6 06:24:31 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 6 Sep 2019 06:24:31 +0000 Subject: 8229280: Test failures on several linux hosts after JDK-8181493 In-Reply-To: References: <2D854054-B445-406B-8777-4D1DA2F95137@oracle.com> <97F6E4AD-3802-4A2C-8043-3158DA323B37@oracle.com> <88BB88A0-AE86-478F-8B9C-EA45F4B7A8C1@oracle.com> <018859AB-83DD-4704-A92A-8FFB50B35970@oracle.com> <7b4c2bd4-4e3d-70f0-9d8b-b0d24ae038a0@oracle.com> <8DE2D4E9-E312-4E73-A692-DE35141BFC2A@oracle.com> <638E1D14-E6F7-4BD1-97F2-1579F437D930@oracle.com> <090F0BD2-244B-4B31-8DA8-E459ADE2F06C@oracle.com> <6AA39403-222D-4E45-950F-465AAA815FBE@oracle.com> <6d6f374a-17a1-e40a-ea68-d282c0bf1c50@oracle.com> Message-ID: Hi Brian, thanks for fixing this. Unfortunately I have been a bit out of game here for the review due to vacation and other stuff but it all seems to make sense to me ?? I?ve just re-enabled the test in our system. I?d let you know in case there were still issues. Thanks Christoph From: nio-dev On Behalf Of Brian Burkhalter Sent: Mittwoch, 4. September 2019 22:05 To: Alan Bateman Cc: nio-dev Subject: Re: 8229280: Test failures on several linux hosts after JDK-8181493 On Sep 4, 2019, at 12:24 PM, Alan Bateman > wrote: On 04/09/2019 20:09, Brian Burkhalter wrote: Here is an updated version which should address the foregoing problems: http://cr.openjdk.java.net/~bpb/8229280/webrev.02/ Good, this is much easier to maintain. A minor nit is that the testedTypes should be a Set to avoid the raw type warning. Also if you allow the lines to be just a bit longer then it would avoid the awkward line breaks at L46, 48, 52, and 65. I have applied the foregoing changes at http://cr.openjdk.java.net/~bpb/8229280/webrev.03/. Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From shade at redhat.com Fri Sep 6 08:36:26 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 6 Sep 2019 10:36:26 +0200 Subject: [11u] RFR: 8229887: (zipfs) zip file corruption when replacing an existing STORED entry In-Reply-To: References: Message-ID: <89e7b892-cce7-8b4e-46bc-12be931e3ac4@redhat.com> On 9/5/19 12:26 PM, Langer, Christoph wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8229887 > Original Change: https://hg.openjdk.java.net/jdk/jdk/rev/abf6ee4c477c > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8229887.11u.0/ Backport looks good. > The original patch applies cleanly but the method java.nio.file.FileSystems::newFileSystem(Path > path) that is used in the test was only introduced in JDK13. So I have to fallback to > java.nio.file.FileSystems:: newFileSystem(Path path, ClassLoader loader) at these places (lines > 123, 163 and 195 of UpdateEntryTest). With this modification, the test passes. Have you tried if the new test fails without the product patch? -- Thanks, -Aleksey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From christoph.langer at sap.com Fri Sep 6 09:35:12 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 6 Sep 2019 09:35:12 +0000 Subject: [11u] RFR: 8229887: (zipfs) zip file corruption when replacing an existing STORED entry In-Reply-To: <89e7b892-cce7-8b4e-46bc-12be931e3ac4@redhat.com> References: <89e7b892-cce7-8b4e-46bc-12be931e3ac4@redhat.com> Message-ID: Hi, > > Bug: https://bugs.openjdk.java.net/browse/JDK-8229887 > > Original Change: https://hg.openjdk.java.net/jdk/jdk/rev/abf6ee4c477c > > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8229887.11u.0/ > > Backport looks good. Thanks for reviewing this. > > The original patch applies cleanly but the method java.nio.file.FileSystems::newFileSystem(Path > > path) that is used in the test was only introduced in JDK13. So I have to fallback to > > java.nio.file.FileSystems:: newFileSystem(Path path, ClassLoader loader) at these places (lines > > 123, 163 and 195 of UpdateEntryTest). With this modification, the test passes. > Have you tried if the new test fails without the product patch? Yes, I have. The failure can be reproduced. Will push it to jdk11u then. Best regards Christoph From shade at redhat.com Fri Sep 6 09:38:57 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 6 Sep 2019 11:38:57 +0200 Subject: [11u] RFR: 8229887: (zipfs) zip file corruption when replacing an existing STORED entry In-Reply-To: References: <89e7b892-cce7-8b4e-46bc-12be931e3ac4@redhat.com> Message-ID: On 9/6/19 11:35 AM, Langer, Christoph wrote: > Will push it to jdk11u then. Feels right. -- Thanks, -Aleksey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From vkempik at azul.com Fri Sep 6 13:59:27 2019 From: vkempik at azul.com (Vladimir Kempik) Date: Fri, 6 Sep 2019 13:59:27 +0000 Subject: RFR: 8229872: (fs) Increase buffer size used with getmntent In-Reply-To: <24d7ea75-53d0-bd2e-0199-d2d0457a071d@oracle.com> References: <1DF90E8C-07FB-4809-A2AD-04D9D0F2FF0D@azul.com> <0FB89DBB-566C-4E32-8131-C15FA659022D@azul.com> <8736hvoqa3.fsf@oldenburg2.str.redhat.com> <20BDB142-8E77-4886-9902-CB1DE5CC4930@azul.com> <503abeab-0aae-937a-5c4b-b022e5f10dd1@oracle.com> <87a7bzsyyh.fsf@oldenburg2.str.redhat.com> <0D734383-604F-414C-9F5D-27E5C617E04F@azul.com> <05113D4C-1258-4502-9D5F-D1BE4C4BA5ED@azul.com> <4840e25c-4794-22bb-bc62-d1103d1988a1@oracle.com> <11AAA5FB-BD27-4E20-B4D8-24CC9A99E017@azul.com> <179c534c-9a83-4a14-7023-fe332bdcdd8a@oracle.com> <24d7ea75-53d0-bd2e-0199-d2d0457a071d@oracle.com> Message-ID: <008017FD-4FEC-4E21-B73C-73AB8B3EBE93@azul.com> Hello Thanks for comments updated webrev including all mentioned things. http://cr.openjdk.java.net/~vkempik/8229872/webrev.08/ Thanks, Vladimir > 5 ????. 2019 ?., ? 11:52, Alan Bateman ???????(?): > > On 04/09/2019 16:56, Vladimir Kempik wrote: >> Hello >> After thinking about it, I think it?s better to leave getlinelen as is, and just increase maxLineSize by one in getMountEntries. >> >> here is webrev: http://cr.openjdk.java.net/~vkempik/8229872/webrev.07/ > UnixNativeDispatcher.rewind - the comment L413-419 needs cleanup, I think should be one line or just removed. > > UnixNativeDispatcher.getlinelen - the function description is confusing. I think it should be removed or replaced with something simple that explains that it returns the line length (without the NUL terminator) or -1 when at EOF. I see Florian's mail that -1 can be EOF or an error and I agree this needs to be cleaned up. > > LinuxNativeDispatcher.getmntent - the parameter to the native method should be bufLen to match the libc function that it calls. Also I think we should try to keep the formatting/style consistent with the existing code, meaning the NULL checks should be "if (bytes == NULL) {" rather than putting the open brace on a new line. > > LinuxFileSystem.getMountEntries. - maxLineSize++ in the finally block is confusing. I think it would be cleaner to have the following after the finally block: > long bufLen = maxLineLen + 1; > and then call getmntent with bugLen. This will avoid misleading further maintainers into thinking that maxLineLen is the maxium line length. > At L88 you need a line break to put the statement on the next line (to keep it consistent with the existing code). > > -Alan. > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From fweimer at redhat.com Fri Sep 6 15:03:11 2019 From: fweimer at redhat.com (Florian Weimer) Date: Fri, 06 Sep 2019 17:03:11 +0200 Subject: RFR: 8229872: (fs) Increase buffer size used with getmntent In-Reply-To: <008017FD-4FEC-4E21-B73C-73AB8B3EBE93@azul.com> (Vladimir Kempik's message of "Fri, 6 Sep 2019 13:59:27 +0000") References: <1DF90E8C-07FB-4809-A2AD-04D9D0F2FF0D@azul.com> <8736hvoqa3.fsf@oldenburg2.str.redhat.com> <20BDB142-8E77-4886-9902-CB1DE5CC4930@azul.com> <503abeab-0aae-937a-5c4b-b022e5f10dd1@oracle.com> <87a7bzsyyh.fsf@oldenburg2.str.redhat.com> <0D734383-604F-414C-9F5D-27E5C617E04F@azul.com> <05113D4C-1258-4502-9D5F-D1BE4C4BA5ED@azul.com> <4840e25c-4794-22bb-bc62-d1103d1988a1@oracle.com> <11AAA5FB-BD27-4E20-B4D8-24CC9A99E017@azul.com> <179c534c-9a83-4a14-7023-fe332bdcdd8a@oracle.com> <24d7ea75-53d0-bd2e-0199-d2d0457a071d@oracle.com> <008017FD-4FEC-4E21-B73C-73AB8B3EBE93@azul.com> Message-ID: <87pnkdeac0.fsf@oldenburg2.str.redhat.com> * Vladimir Kempik: > Hello > > Thanks for comments > > updated webrev including all mentioned things. > > http://cr.openjdk.java.net/~vkempik/8229872/webrev.08/ In src/java.base/linux/native/libnio/fs/LinuxNativeDispatcher.c: + int buflen = (int)bufLen; The buffer size should be size_t, for consistency with the possible return values of Java_sun_nio_fs_UnixNativeDispatcher_getlinelen. Thanks, Florian From vkempik at azul.com Fri Sep 6 15:12:47 2019 From: vkempik at azul.com (Vladimir Kempik) Date: Fri, 6 Sep 2019 15:12:47 +0000 Subject: RFR: 8229872: (fs) Increase buffer size used with getmntent In-Reply-To: <87pnkdeac0.fsf@oldenburg2.str.redhat.com> References: <1DF90E8C-07FB-4809-A2AD-04D9D0F2FF0D@azul.com> <8736hvoqa3.fsf@oldenburg2.str.redhat.com> <20BDB142-8E77-4886-9902-CB1DE5CC4930@azul.com> <503abeab-0aae-937a-5c4b-b022e5f10dd1@oracle.com> <87a7bzsyyh.fsf@oldenburg2.str.redhat.com> <0D734383-604F-414C-9F5D-27E5C617E04F@azul.com> <05113D4C-1258-4502-9D5F-D1BE4C4BA5ED@azul.com> <4840e25c-4794-22bb-bc62-d1103d1988a1@oracle.com> <11AAA5FB-BD27-4E20-B4D8-24CC9A99E017@azul.com> <179c534c-9a83-4a14-7023-fe332bdcdd8a@oracle.com> <24d7ea75-53d0-bd2e-0199-d2d0457a071d@oracle.com> <008017FD-4FEC-4E21-B73C-73AB8B3EBE93@azul.com> <87pnkdeac0.fsf@oldenburg2.str.redhat.com> Message-ID: Hello such custing (from long to int) were needed only because getmntent_r expects last argument to be int https://linux.die.net/man/3/getmntent_r struct mntent *getmntent_r(FILE *fp, struct mntent *mntbuf, char *buf, int buflen); so could you please clarify ? since getlinelen returns long, I see no issue so far. Thanks, Vladimir 6 ????. 2019 ?., ? 18:03, Florian Weimer > ???????(?): * Vladimir Kempik: Hello Thanks for comments updated webrev including all mentioned things. http://cr.openjdk.java.net/~vkempik/8229872/webrev.08/ In src/java.base/linux/native/libnio/fs/LinuxNativeDispatcher.c: + int buflen = (int)bufLen; The buffer size should be size_t, for consistency with the possible return values of Java_sun_nio_fs_UnixNativeDispatcher_getlinelen. Thanks, Florian -------------- next part -------------- An HTML attachment was scrubbed... URL: From vtewar26 at in.ibm.com Fri Sep 6 15:21:04 2019 From: vtewar26 at in.ibm.com (Vyom Tewari26) Date: Fri, 6 Sep 2019 15:21:04 +0000 Subject: RFR: 8229872: (fs) Increase buffer size used with getmntent In-Reply-To: <008017FD-4FEC-4E21-B73C-73AB8B3EBE93@azul.com> References: <008017FD-4FEC-4E21-B73C-73AB8B3EBE93@azul.com>, <1DF90E8C-07FB-4809-A2AD-04D9D0F2FF0D@azul.com> <0FB89DBB-566C-4E32-8131-C15FA659022D@azul.com> <8736hvoqa3.fsf@oldenburg2.str.redhat.com> <20BDB142-8E77-4886-9902-CB1DE5CC4930@azul.com> <503abeab-0aae-937a-5c4b-b022e5f10dd1@oracle.com> <87a7bzsyyh.fsf@oldenburg2.str.redhat.com> <0D734383-604F-414C-9F5D-27E5C617E04F@azul.com> <05113D4C-1258-4502-9D5F-D1BE4C4BA5ED@azul.com> <4840e25c-4794-22bb-bc62-d1103d1988a1@oracle.com> <11AAA5FB-BD27-4E20-B4D8-24CC9A99E017@azul.com> <179c534c-9a83-4a14-7023-fe332bdcdd8a@oracle.com> <24d7ea75-53d0-bd2e-0199-d2d0457a071d@oracle.com> Message-ID: An HTML attachment was scrubbed... URL: From hohensee at amazon.com Fri Sep 6 18:03:27 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Fri, 6 Sep 2019 18:03:27 +0000 Subject: [11u] RFR: 8229887: (zipfs) zip file corruption when replacing an existing STORED entry In-Reply-To: References: Message-ID: Looks good. Paul ?On 9/5/19, 3:28 AM, "jdk-updates-dev on behalf of Langer, Christoph" wrote: Hi, may I please get a review for the backport of this item to jdk11 updates: Bug: https://bugs.openjdk.java.net/browse/JDK-8229887 Original Change: https://hg.openjdk.java.net/jdk/jdk/rev/abf6ee4c477c Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8229887.11u.0/ The original patch applies cleanly but the method java.nio.file.FileSystems::newFileSystem(Path path) that is used in the test was only introduced in JDK13. So I have to fallback to java.nio.file.FileSystems:: newFileSystem(Path path, ClassLoader loader) at these places (lines 123, 163 and 195 of UpdateEntryTest). With this modification, the test passes. Thanks Christoph From Alan.Bateman at oracle.com Sun Sep 8 07:49:55 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 8 Sep 2019 08:49:55 +0100 Subject: RFR: 8229872: (fs) Increase buffer size used with getmntent In-Reply-To: <008017FD-4FEC-4E21-B73C-73AB8B3EBE93@azul.com> References: <1DF90E8C-07FB-4809-A2AD-04D9D0F2FF0D@azul.com> <20BDB142-8E77-4886-9902-CB1DE5CC4930@azul.com> <503abeab-0aae-937a-5c4b-b022e5f10dd1@oracle.com> <87a7bzsyyh.fsf@oldenburg2.str.redhat.com> <0D734383-604F-414C-9F5D-27E5C617E04F@azul.com> <05113D4C-1258-4502-9D5F-D1BE4C4BA5ED@azul.com> <4840e25c-4794-22bb-bc62-d1103d1988a1@oracle.com> <11AAA5FB-BD27-4E20-B4D8-24CC9A99E017@azul.com> <179c534c-9a83-4a14-7023-fe332bdcdd8a@oracle.com> <24d7ea75-53d0-bd2e-0199-d2d0457a071d@oracle.com> <008017FD-4FEC-4E21-B73C-73AB8B3EBE93@azul.com> Message-ID: On 06/09/2019 14:59, Vladimir Kempik wrote: > Hello > > Thanks for comments > > updated webrev including all mentioned things. > > http://cr.openjdk.java.net/~vkempik/8229872/webrev.08/ > I think this is getting better. One thing that would help is a pointer to documentation that confirms that getmntent_r may realloc buf as I don't see this in the man page. Some specific comments on webrev.08 LinuxFileSystem.java L98 - this sets buflen to maxLineSize before incrementing maxLineSize, should be "buflen = maxLineSize + 1". I'm also wondering if maxLineSize should be an int rather than a long as the native code has to cast it to a size_t or native int. LinuxNativeDispatcher.c - I would prefer not to have both buflen and bufLen. No one type will work for all cases so I think you have to case to size_t for malloc and int for getmntent_r. -Alan From vkempik at azul.com Sun Sep 8 08:38:22 2019 From: vkempik at azul.com (Vladimir Kempik) Date: Sun, 8 Sep 2019 08:38:22 +0000 Subject: RFR: 8229872: (fs) Increase buffer size used with getmntent In-Reply-To: References: <1DF90E8C-07FB-4809-A2AD-04D9D0F2FF0D@azul.com> <20BDB142-8E77-4886-9902-CB1DE5CC4930@azul.com> <503abeab-0aae-937a-5c4b-b022e5f10dd1@oracle.com> <87a7bzsyyh.fsf@oldenburg2.str.redhat.com> <0D734383-604F-414C-9F5D-27E5C617E04F@azul.com> <05113D4C-1258-4502-9D5F-D1BE4C4BA5ED@azul.com> <4840e25c-4794-22bb-bc62-d1103d1988a1@oracle.com> <11AAA5FB-BD27-4E20-B4D8-24CC9A99E017@azul.com> <179c534c-9a83-4a14-7023-fe332bdcdd8a@oracle.com> <24d7ea75-53d0-bd2e-0199-d2d0457a071d@oracle.com> <008017FD-4FEC-4E21-B73C-73AB8B3EBE93@azul.com> Message-ID: Hello Alan. Its not getmntent, its getline who can realloc Regards, Vladimir Alan Bateman 8 ???????? 2019 ?. 10:50:12 ???????: > On 06/09/2019 14:59, Vladimir Kempik wrote: >> Hello >> >> Thanks for comments >> >> updated webrev including all mentioned things. >> >> http://cr.openjdk.java.net/~vkempik/8229872/webrev.08/ >> > I think this is getting better. One thing that would help is a pointer > to documentation that confirms that getmntent_r may realloc buf as I > don't see this in the man page. > > Some specific comments on webrev.08 > > LinuxFileSystem.java L98 - this sets buflen to maxLineSize before > incrementing maxLineSize, should be "buflen = maxLineSize + 1". I'm also > wondering if maxLineSize should be an int rather than a long as the > native code has to cast it to a size_t or native int. > > LinuxNativeDispatcher.c - I would prefer not to have both buflen and > bufLen. No one type will work for all cases so I think you have to case > to size_t for malloc and int for getmntent_r. > > -Alan From Alan.Bateman at oracle.com Sun Sep 8 08:44:17 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 8 Sep 2019 09:44:17 +0100 Subject: RFR: 8229872: (fs) Increase buffer size used with getmntent In-Reply-To: References: <1DF90E8C-07FB-4809-A2AD-04D9D0F2FF0D@azul.com> <87a7bzsyyh.fsf@oldenburg2.str.redhat.com> <0D734383-604F-414C-9F5D-27E5C617E04F@azul.com> <05113D4C-1258-4502-9D5F-D1BE4C4BA5ED@azul.com> <4840e25c-4794-22bb-bc62-d1103d1988a1@oracle.com> <11AAA5FB-BD27-4E20-B4D8-24CC9A99E017@azul.com> <179c534c-9a83-4a14-7023-fe332bdcdd8a@oracle.com> <24d7ea75-53d0-bd2e-0199-d2d0457a071d@oracle.com> <008017FD-4FEC-4E21-B73C-73AB8B3EBE93@azul.com> Message-ID: <54822b99-52d2-edd7-9812-8e6829ec9a06@oracle.com> On 08/09/2019 09:38, Vladimir Kempik wrote: > Hello Alan. > Its not getmntent, its getline who can realloc > Regards, Vladimir > Good, that's what I thought. This means that we don't need to change getmntent to use malloc/free. In its place, we just change the Java method to get a NativeBuffer and pass the address (and buflen) to the native function. This will simplify the patch and also keep it consistent with the existing code. -Alan From fweimer at redhat.com Mon Sep 9 12:17:47 2019 From: fweimer at redhat.com (Florian Weimer) Date: Mon, 09 Sep 2019 14:17:47 +0200 Subject: RFR: 8229872: (fs) Increase buffer size used with getmntent In-Reply-To: (Vladimir Kempik's message of "Fri, 6 Sep 2019 15:12:47 +0000") References: <1DF90E8C-07FB-4809-A2AD-04D9D0F2FF0D@azul.com> <503abeab-0aae-937a-5c4b-b022e5f10dd1@oracle.com> <87a7bzsyyh.fsf@oldenburg2.str.redhat.com> <0D734383-604F-414C-9F5D-27E5C617E04F@azul.com> <05113D4C-1258-4502-9D5F-D1BE4C4BA5ED@azul.com> <4840e25c-4794-22bb-bc62-d1103d1988a1@oracle.com> <11AAA5FB-BD27-4E20-B4D8-24CC9A99E017@azul.com> <179c534c-9a83-4a14-7023-fe332bdcdd8a@oracle.com> <24d7ea75-53d0-bd2e-0199-d2d0457a071d@oracle.com> <008017FD-4FEC-4E21-B73C-73AB8B3EBE93@azul.com> <87pnkdeac0.fsf@oldenburg2.str.redhat.com> Message-ID: <87h85l7jf8.fsf@oldenburg2.str.redhat.com> * Vladimir Kempik: > Hello > such custing (from long to int) were needed only because getmntent_r expects last argument to be int > > https://linux.die.net/man/3/getmntent_r > struct mntent *getmntent_r(FILE *fp, struct mntent *mntbuf, char *buf, int buflen); > > so could you please clarify ? Hmm. Indeed. It looks like our implementation getmntent_r returns NULL without setting errno if buflen is negative. > since getlinelen returns long, I see no issue so far. What if getlinelen computes a line length longer than INT_MAX? I think all the uses are consistent here, so it is not an immediately problem. Would it make sense to check for INT_MAX in Java_sun_nio_fs_UnixNativeDispatcher_getlinelen and throw an exception (say with EOVERFLOW) there? Thanks, Florian From vkempik at azul.com Wed Sep 11 11:27:09 2019 From: vkempik at azul.com (Vladimir Kempik) Date: Wed, 11 Sep 2019 11:27:09 +0000 Subject: RFR: 8229872: (fs) Increase buffer size used with getmntent In-Reply-To: <87h85l7jf8.fsf@oldenburg2.str.redhat.com> References: <1DF90E8C-07FB-4809-A2AD-04D9D0F2FF0D@azul.com> <503abeab-0aae-937a-5c4b-b022e5f10dd1@oracle.com> <87a7bzsyyh.fsf@oldenburg2.str.redhat.com> <0D734383-604F-414C-9F5D-27E5C617E04F@azul.com> <05113D4C-1258-4502-9D5F-D1BE4C4BA5ED@azul.com> <4840e25c-4794-22bb-bc62-d1103d1988a1@oracle.com> <11AAA5FB-BD27-4E20-B4D8-24CC9A99E017@azul.com> <179c534c-9a83-4a14-7023-fe332bdcdd8a@oracle.com> <24d7ea75-53d0-bd2e-0199-d2d0457a071d@oracle.com> <008017FD-4FEC-4E21-B73C-73AB8B3EBE93@azul.com> <87pnkdeac0.fsf@oldenburg2.str.redhat.com> <87h85l7jf8.fsf@oldenburg2.str.redhat.com> Message-ID: Hello Please take a look at v9 of webrev http://cr.openjdk.java.net/~vkempik/8229872/webrev.09/ changes: - getlinelen returns int and all linelens in java are ints now - integer overflow check at the end of getlinelen - getmntent_r now uses nativebuffer instead of malloc/free Thanks, Vladimir > 9 ????. 2019 ?., ? 15:17, Florian Weimer ???????(?): > > * Vladimir Kempik: > >> Hello >> such custing (from long to int) were needed only because getmntent_r expects last argument to be int >> >> https://linux.die.net/man/3/getmntent_r >> struct mntent *getmntent_r(FILE *fp, struct mntent *mntbuf, char *buf, int buflen); >> >> so could you please clarify ? > > Hmm. Indeed. It looks like our implementation getmntent_r returns NULL > without setting errno if buflen is negative. > >> since getlinelen returns long, I see no issue so far. > > What if getlinelen computes a line length longer than INT_MAX? I think > all the uses are consistent here, so it is not an immediately problem. > > Would it make sense to check for INT_MAX in > Java_sun_nio_fs_UnixNativeDispatcher_getlinelen and throw an exception > (say with EOVERFLOW) there? > > Thanks, > Florian -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From lance.andersen at oracle.com Wed Sep 11 17:22:38 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Wed, 11 Sep 2019 13:22:38 -0400 Subject: RFR 8230870: Add a ZIP FS test that is similar to test/jdk/java/util/zip/EntryCount64k.java Message-ID: <89DF3E27-8A04-430B-B28D-DB2C23732BA2@oracle.com> Hi all, Please review the addition of a ZIP FS test which is similar to test/jdk/java/util/zip/EntryCount64k.java The test exercises the ZIP FS properties noCompression and forceZIP64End which we do not have much coverage for. The test runs clean Mach5 and and I run it 100 times each on windows-x64, macosx-x64, linux-x64 and linux-x64-open platforms to sanity check there are no potential timeout issues due to the test run I have left some basic timing methods in the test but have disabled them in the unlikely event we have to revisit a timeout issue. The webrev can be found at: http://cr.openjdk.java.net/~lancea/8230870/webrev.00/ Best Lance 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 Alan.Bateman at oracle.com Wed Sep 11 19:42:34 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 11 Sep 2019 20:42:34 +0100 Subject: RFR: 8229872: (fs) Increase buffer size used with getmntent In-Reply-To: References: <1DF90E8C-07FB-4809-A2AD-04D9D0F2FF0D@azul.com> <87a7bzsyyh.fsf@oldenburg2.str.redhat.com> <0D734383-604F-414C-9F5D-27E5C617E04F@azul.com> <05113D4C-1258-4502-9D5F-D1BE4C4BA5ED@azul.com> <4840e25c-4794-22bb-bc62-d1103d1988a1@oracle.com> <11AAA5FB-BD27-4E20-B4D8-24CC9A99E017@azul.com> <179c534c-9a83-4a14-7023-fe332bdcdd8a@oracle.com> <24d7ea75-53d0-bd2e-0199-d2d0457a071d@oracle.com> <008017FD-4FEC-4E21-B73C-73AB8B3EBE93@azul.com> <87pnkdeac0.fsf@oldenburg2.str.redhat.com> <87h85l7jf8.fsf@oldenburg2.str.redhat.com> Message-ID: <3bd722e8-6290-60ff-af9f-d5d6a63f1218@oracle.com> On 11/09/2019 12:27, Vladimir Kempik wrote: > Hello > > Please take a look at v9 of webrev > http://cr.openjdk.java.net/~vkempik/8229872/webrev.09/ > > changes: > ?- getlinelen returns int and all linelens in java are ints now > ?- integer overflow check at the end of getlinelen > ?- getmntent_r now uses nativebuffer instead of malloc/free > The getmnent method doesn't look right, this is what you want: static int getmntent(long fp, UnixMountEntry entry, buflen) throws UnixException { ??? NativeBuffer buffer = NativeBuffers.getNativeBuffer(buflen); ??? try { ??????? return getmntent0(fp, UnixMountEntry, buffer.address(), buflen); ??? } finally { ??????? buffer.release(); ??? } } This will simplify getMountEntries as you will call it with getmntent(fp, entry, maxLineSize+1). -Alan From vkempik at azul.com Thu Sep 12 14:47:24 2019 From: vkempik at azul.com (Vladimir Kempik) Date: Thu, 12 Sep 2019 14:47:24 +0000 Subject: RFR: 8229872: (fs) Increase buffer size used with getmntent In-Reply-To: <3bd722e8-6290-60ff-af9f-d5d6a63f1218@oracle.com> References: <1DF90E8C-07FB-4809-A2AD-04D9D0F2FF0D@azul.com> <87a7bzsyyh.fsf@oldenburg2.str.redhat.com> <0D734383-604F-414C-9F5D-27E5C617E04F@azul.com> <05113D4C-1258-4502-9D5F-D1BE4C4BA5ED@azul.com> <4840e25c-4794-22bb-bc62-d1103d1988a1@oracle.com> <11AAA5FB-BD27-4E20-B4D8-24CC9A99E017@azul.com> <179c534c-9a83-4a14-7023-fe332bdcdd8a@oracle.com> <24d7ea75-53d0-bd2e-0199-d2d0457a071d@oracle.com> <008017FD-4FEC-4E21-B73C-73AB8B3EBE93@azul.com> <87pnkdeac0.fsf@oldenburg2.str.redhat.com> <87h85l7jf8.fsf@oldenburg2.str.redhat.com> <3bd722e8-6290-60ff-af9f-d5d6a63f1218@oracle.com> Message-ID: Thanks Alan Updated webrev with changed getmntent: http://cr.openjdk.java.net/~vkempik/8229872/webrev.10 Regards, Vladimir. > 11 ????. 2019 ?., ? 22:42, Alan Bateman ???????(?): > > > On 11/09/2019 12:27, Vladimir Kempik wrote: >> Hello >> >> Please take a look at v9 of webrev http://cr.openjdk.java.net/~vkempik/8229872/webrev.09/ >> >> changes: >> - getlinelen returns int and all linelens in java are ints now >> - integer overflow check at the end of getlinelen >> - getmntent_r now uses nativebuffer instead of malloc/free >> > The getmnent method doesn't look right, this is what you want: > > static int getmntent(long fp, UnixMountEntry entry, buflen) throws UnixException { > NativeBuffer buffer = NativeBuffers.getNativeBuffer(buflen); > try { > return getmntent0(fp, UnixMountEntry, buffer.address(), buflen); > } finally { > buffer.release(); > } > } > > This will simplify getMountEntries as you will call it with getmntent(fp, entry, maxLineSize+1). > > -Alan > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From Alan.Bateman at oracle.com Thu Sep 12 18:54:15 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 12 Sep 2019 19:54:15 +0100 Subject: RFR: 8229872: (fs) Increase buffer size used with getmntent In-Reply-To: References: <1DF90E8C-07FB-4809-A2AD-04D9D0F2FF0D@azul.com> <05113D4C-1258-4502-9D5F-D1BE4C4BA5ED@azul.com> <4840e25c-4794-22bb-bc62-d1103d1988a1@oracle.com> <11AAA5FB-BD27-4E20-B4D8-24CC9A99E017@azul.com> <179c534c-9a83-4a14-7023-fe332bdcdd8a@oracle.com> <24d7ea75-53d0-bd2e-0199-d2d0457a071d@oracle.com> <008017FD-4FEC-4E21-B73C-73AB8B3EBE93@azul.com> <87pnkdeac0.fsf@oldenburg2.str.redhat.com> <87h85l7jf8.fsf@oldenburg2.str.redhat.com> <3bd722e8-6290-60ff-af9f-d5d6a63f1218@oracle.com> Message-ID: <65c8cab4-09cc-d0ac-96eb-da9049d4d9b2@oracle.com> On 12/09/2019 15:47, Vladimir Kempik wrote: > Thanks Alan > > Updated webrev with changed getmntent: > http://cr.openjdk.java.net/~vkempik/8229872/webrev.10 > This version addresses all my comments so I think it looks good. -Alan. From vkempik at azul.com Fri Sep 13 11:32:58 2019 From: vkempik at azul.com (Vladimir Kempik) Date: Fri, 13 Sep 2019 11:32:58 +0000 Subject: RFR: 8229872: (fs) Increase buffer size used with getmntent In-Reply-To: <65c8cab4-09cc-d0ac-96eb-da9049d4d9b2@oracle.com> References: <1DF90E8C-07FB-4809-A2AD-04D9D0F2FF0D@azul.com> <05113D4C-1258-4502-9D5F-D1BE4C4BA5ED@azul.com> <4840e25c-4794-22bb-bc62-d1103d1988a1@oracle.com> <11AAA5FB-BD27-4E20-B4D8-24CC9A99E017@azul.com> <179c534c-9a83-4a14-7023-fe332bdcdd8a@oracle.com> <24d7ea75-53d0-bd2e-0199-d2d0457a071d@oracle.com> <008017FD-4FEC-4E21-B73C-73AB8B3EBE93@azul.com> <87pnkdeac0.fsf@oldenburg2.str.redhat.com> <87h85l7jf8.fsf@oldenburg2.str.redhat.com> <3bd722e8-6290-60ff-af9f-d5d6a63f1218@oracle.com> <65c8cab4-09cc-d0ac-96eb-da9049d4d9b2@oracle.com> Message-ID: <41F66CCF-2A37-487C-BD6E-64052BA6C25A@azul.com> Hello just to make sure: after second review from smbd else, it should be pushed to http://hg.openjdk.java.net/jdk/jdk/ , right? Thanks. > 12 ????. 2019 ?., ? 21:54, Alan Bateman ???????(?): > > On 12/09/2019 15:47, Vladimir Kempik wrote: >> Thanks Alan >> >> Updated webrev with changed getmntent: http://cr.openjdk.java.net/~vkempik/8229872/webrev.10 >> > This version addresses all my comments so I think it looks good. > > -Alan. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From Alan.Bateman at oracle.com Fri Sep 13 11:58:02 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 13 Sep 2019 12:58:02 +0100 Subject: RFR: 8229872: (fs) Increase buffer size used with getmntent In-Reply-To: <41F66CCF-2A37-487C-BD6E-64052BA6C25A@azul.com> References: <1DF90E8C-07FB-4809-A2AD-04D9D0F2FF0D@azul.com> <4840e25c-4794-22bb-bc62-d1103d1988a1@oracle.com> <11AAA5FB-BD27-4E20-B4D8-24CC9A99E017@azul.com> <179c534c-9a83-4a14-7023-fe332bdcdd8a@oracle.com> <24d7ea75-53d0-bd2e-0199-d2d0457a071d@oracle.com> <008017FD-4FEC-4E21-B73C-73AB8B3EBE93@azul.com> <87pnkdeac0.fsf@oldenburg2.str.redhat.com> <87h85l7jf8.fsf@oldenburg2.str.redhat.com> <3bd722e8-6290-60ff-af9f-d5d6a63f1218@oracle.com> <65c8cab4-09cc-d0ac-96eb-da9049d4d9b2@oracle.com> <41F66CCF-2A37-487C-BD6E-64052BA6C25A@azul.com> Message-ID: On 13/09/2019 12:32, Vladimir Kempik wrote: > Hello > just to make sure: after second review from smbd else, it should be > pushed to http://hg.openjdk.java.net/jdk/jdk/, right? > The changes only requires one reviewer but since Florian took a close interest and was very helpful then I hope he will reply too. I checked the census and I see you have Committer role on the jdk-updates and jdk8u projects but not the jdk project. Is there someone in Azul that will sponsor/push this for you or do you want me to do it? -Alan. From brian.burkhalter at oracle.com Fri Sep 13 14:42:31 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 13 Sep 2019 07:42:31 -0700 Subject: 8230085: (fs) FileStore::isReadOnly is always true on macOS Catalina Message-ID: https://bugs.openjdk.java.net/browse/JDK-8230085 http://cr.openjdk.java.net/~bpb/8230085/webrev.00/ In macOS Catalina the system volume is replaced with a volume group consisting of a read-only system volume and a read-write data volume. The latter is at /Systems/Volumes/Data. A number of ?firmlinks? (cf. /usr/share/firmlinks) define bi-directional traversal points between the read-only and read-write volumes. Examples of these are /Users and /private (which includes /private/tmp). This change caused a failure due to the algorithm used to attempt to identify the FileStore containing a given path. This algorithm using the device ID (stat.st_dev) which turns out to be the same for the system and data volumes and is therefore unreliable to this purpose. This patch proposes to use statfs.f_mntonname to identify the volume containing a given path in step 2 of sub.nio.fs.BsdFileStore.findMountEntry(). A new method is added to retrieve f_mntonname. This could have been made an attribute but this would be redundant with the FilStore and would add attribute baggage to the file. One question is whether f_mntonname should also be used in creating the list of FileStores. Thanks, Brian From Alan.Bateman at oracle.com Fri Sep 13 16:46:06 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 13 Sep 2019 17:46:06 +0100 Subject: 8230085: (fs) FileStore::isReadOnly is always true on macOS Catalina In-Reply-To: References: Message-ID: <02dee6b8-7342-ff93-a09f-108d6aaf00e7@oracle.com> On 13/09/2019 15:42, Brian Burkhalter wrote: > : > > One question is whether f_mntonname should also be used in creating the list of FileStores. > Can you elaborate on this question? When the underlying file systems are enumerated with getfsstat then the BsdFileStore instances will be created with the dir field set to mount point (f_mntonname). So it should be used already. -Alan From brian.burkhalter at oracle.com Fri Sep 13 16:50:27 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 13 Sep 2019 09:50:27 -0700 Subject: 8230085: (fs) FileStore::isReadOnly is always true on macOS Catalina In-Reply-To: <02dee6b8-7342-ff93-a09f-108d6aaf00e7@oracle.com> References: <02dee6b8-7342-ff93-a09f-108d6aaf00e7@oracle.com> Message-ID: <736C161A-7F1A-4AB9-8FDE-6442E430E913@oracle.com> > On Sep 13, 2019, at 9:46 AM, Alan Bateman wrote: > > On 13/09/2019 15:42, Brian Burkhalter wrote: >> : >> >> One question is whether f_mntonname should also be used in creating the list of FileStores. >> > Can you elaborate on this question? When the underlying file systems are enumerated with getfsstat then the BsdFileStore instances will be created with the dir field set to mount point (f_mntonname). So it should be used already. That is correct - BsdNativeDispatcher.c: dir = iter->buf[iter->pos].f_mntonname; [?] len = strlen(dir); bytes = (*env)->NewByteArray(env, len); if (bytes == NULL) return -1; (*env)->SetByteArrayRegion(env, bytes, 0, len, (jbyte*)dir); (*env)->SetObjectField(env, entry, entry_dir, bytes); My comment was mostly a reminder to myself to double check this code. So I think the list of entries is already OK. Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Fri Sep 13 17:16:44 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 13 Sep 2019 18:16:44 +0100 Subject: 8230085: (fs) FileStore::isReadOnly is always true on macOS Catalina In-Reply-To: <736C161A-7F1A-4AB9-8FDE-6442E430E913@oracle.com> References: <02dee6b8-7342-ff93-a09f-108d6aaf00e7@oracle.com> <736C161A-7F1A-4AB9-8FDE-6442E430E913@oracle.com> Message-ID: <93f2dc66-3f3f-6093-069d-e2cb7e75b65a@oracle.com> On 13/09/2019 17:50, Brian Burkhalter wrote: > > My comment was mostly a reminder to myself to double check this code. > So I think the list of entries is already OK. > > Yes, I think it's okay and there are no issues with FileStore equality. So I think this approach is good. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Fri Sep 13 19:35:11 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 13 Sep 2019 12:35:11 -0700 Subject: 8230085: (fs) FileStore::isReadOnly is always true on macOS Catalina In-Reply-To: <93f2dc66-3f3f-6093-069d-e2cb7e75b65a@oracle.com> References: <02dee6b8-7342-ff93-a09f-108d6aaf00e7@oracle.com> <736C161A-7F1A-4AB9-8FDE-6442E430E913@oracle.com> <93f2dc66-3f3f-6093-069d-e2cb7e75b65a@oracle.com> Message-ID: > On Sep 13, 2019, at 10:16 AM, Alan Bateman wrote: > > On 13/09/2019 17:50, Brian Burkhalter wrote: >> >> My comment was mostly a reminder to myself to double check this code. So I think the list of entries is already OK. >> >> > Yes, I think it's okay and there are no issues with FileStore equality. So I think this approach is good. Good. It already passed all three CI testing tiers on pre-Catalina systems and the java/nio tests on Catalina. I?m going to run some more tests on Catalina and will likely hold off pushing until Monday. Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Sat Sep 14 06:44:31 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 14 Sep 2019 07:44:31 +0100 Subject: 8230085: (fs) FileStore::isReadOnly is always true on macOS Catalina In-Reply-To: References: <02dee6b8-7342-ff93-a09f-108d6aaf00e7@oracle.com> <736C161A-7F1A-4AB9-8FDE-6442E430E913@oracle.com> <93f2dc66-3f3f-6093-069d-e2cb7e75b65a@oracle.com> Message-ID: <913456ef-7924-a366-e209-9d599745cf4b@oracle.com> On 13/09/2019 20:35, Brian Burkhalter wrote: > : > > Good. It already passed all three CI testing tiers on pre-Catalina > systems and the java/nio tests on Catalina. I?m going to run some more > tests on Catalina and will likely hold off pushing until Monday. One other thing to check is that access(2) does the right thing on both the read-only and read-write parts of the file system. Also is there any merit to creating a test that exercises a selection of the APIs with paths to files in the read-only part? -Alan From christoph.langer at sap.com Mon Sep 16 07:59:02 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 16 Sep 2019 07:59:02 +0000 Subject: RFR 8230870: Add a ZIP FS test that is similar to test/jdk/java/util/zip/EntryCount64k.java In-Reply-To: <89DF3E27-8A04-430B-B28D-DB2C23732BA2@oracle.com> References: <89DF3E27-8A04-430B-B28D-DB2C23732BA2@oracle.com> Message-ID: Hi Lance, I looked at the test and also executed it and checked its output. Looks good to me, no comments ?? Best regards Christoph From: nio-dev On Behalf Of Lance Andersen Sent: Mittwoch, 11. September 2019 19:23 To: nio-dev Subject: RFR 8230870: Add a ZIP FS test that is similar to test/jdk/java/util/zip/EntryCount64k.java Hi all, Please review the addition of a ZIP FS test which is similar to test/jdk/java/util/zip/EntryCount64k.java The test exercises the ZIP FS properties noCompression and forceZIP64End which we do not have much coverage for. The test runs clean Mach5 and and I run it 100 times each on windows-x64, macosx-x64, linux-x64 and linux-x64-open platforms to sanity check there are no potential timeout issues due to the test run I have left some basic timing methods in the test but have disabled them in the unlikely event we have to revisit a timeout issue. The webrev can be found at: http://cr.openjdk.java.net/~lancea/8230870/webrev.00/ Best Lance [cid:image001.gif at 01D56C75.5CE320A0] 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: image001.gif Type: image/gif Size: 658 bytes Desc: image001.gif URL: From martinrb at google.com Mon Sep 16 13:43:14 2019 From: martinrb at google.com (Martin Buchholz) Date: Mon, 16 Sep 2019 06:43:14 -0700 Subject: RFR 8230870: Add a ZIP FS test that is similar to test/jdk/java/util/zip/EntryCount64k.java In-Reply-To: <89DF3E27-8A04-430B-B28D-DB2C23732BA2@oracle.com> References: <89DF3E27-8A04-430B-B28D-DB2C23732BA2@oracle.com> Message-ID: Thanks for doing this. Looks Good To Me, but as always I have some comments EntryCount64k was written before testng infrastructure was common. I might have done some surgery on EntryCount64k to accommodate zipfs instead of writing an entirely new test. zipfs adds to the number of ways that zip files can be written - I generally only thought about ZipOutputStream. One can structure zip tests using front-end/back-end strategy: Combine N ways to write a zip file with M ways to read it, and verify that they all work together. But we've never written tests that way. Stop using System.currentTimeMillis for measuring elapsed time, and switch to System.nanoTime. Hmmm .... probably even better here is to hop over nanoTime to using java.time APIs like Duration.between as in https://www.baeldung.com/java-measure-elapsed-time section 3.2 On Wed, Sep 11, 2019 at 10:26 AM Lance Andersen wrote: > Hi all, > > Please review the addition of a ZIP FS test which is similar > to test/jdk/java/util/zip/EntryCount64k.java > > The test exercises the ZIP FS properties noCompression and forceZIP64End > which we do not have much coverage for. > > The test runs clean Mach5 and and I run it 100 times each on windows-x64, macosx-x64, > linux-x64 and linux-x64-open platforms to sanity check there are > no potential timeout issues due to the test run > > I have left some basic timing methods in the test but have disabled them > in the unlikely event we have to revisit a timeout issue. > > The webrev can be found at: > http://cr.openjdk.java.net/~lancea/8230870/webrev.00/ > > Best > Lance > > > > Lance Andersen| > Principal Member of Technical Staff | +1.781.442.2037 <(781)%20442-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 martinrb at google.com Mon Sep 16 14:08:24 2019 From: martinrb at google.com (Martin Buchholz) Date: Mon, 16 Sep 2019 07:08:24 -0700 Subject: RFR 8230870: Add a ZIP FS test that is similar to test/jdk/java/util/zip/EntryCount64k.java In-Reply-To: References: <89DF3E27-8A04-430B-B28D-DB2C23732BA2@oracle.com> Message-ID: On Mon, Sep 16, 2019 at 6:43 AM Martin Buchholz wrote: > Thanks for doing this. > Looks Good To Me, but as always I have some comments > > EntryCount64k was written before testng infrastructure was common. I > might have done some surgery on EntryCount64k to accommodate zipfs instead > of writing an entirely new test. zipfs adds to the number of ways that zip > files can be written - I generally only thought about ZipOutputStream. One > can structure zip tests using front-end/back-end strategy: Combine N ways > to write a zip file with M ways to read it, and verify that they all work > together. But we've never written tests that way. > > Stop using System.currentTimeMillis for measuring elapsed time, and switch > to System.nanoTime. Hmmm .... probably even better here is to hop over > nanoTime to using java.time APIs like Duration.between as in > https://www.baeldung.com/java-measure-elapsed-time section 3.2 > Hmmmmmmmm .............. Wait, it looks like Instant/Duration are also tied to wall clock time. Is it really true that java.time doesn't offer any simple elapsed time utility like e.g. Guava or Apache Stopwatch?! I guess I'll stick to nanoTime in my own tests... -------------- 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 Mon Sep 16 15:45:30 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 16 Sep 2019 08:45:30 -0700 Subject: 8230085: (fs) FileStore::isReadOnly is always true on macOS Catalina In-Reply-To: <913456ef-7924-a366-e209-9d599745cf4b@oracle.com> References: <02dee6b8-7342-ff93-a09f-108d6aaf00e7@oracle.com> <736C161A-7F1A-4AB9-8FDE-6442E430E913@oracle.com> <93f2dc66-3f3f-6093-069d-e2cb7e75b65a@oracle.com> <913456ef-7924-a366-e209-9d599745cf4b@oracle.com> Message-ID: > On Sep 13, 2019, at 11:44 PM, Alan Bateman wrote: > > On 13/09/2019 20:35, Brian Burkhalter wrote: >> : >> >> Good. It already passed all three CI testing tiers on pre-Catalina systems and the java/nio tests on Catalina. I?m going to run some more tests on Catalina and will likely hold off pushing until Monday. > One other thing to check is that access(2) does the right thing on both the read-only and read-write parts of the file system. I?ll check that out. > Also is there any merit to creating a test that exercises a selection of the APIs with paths to files in the read-only part? Perhaps. I was actually wondering whether I should have added something to existing tests despite this problem having already been detected by FileStore/Basic.java. Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From lance.andersen at oracle.com Mon Sep 16 16:08:07 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Mon, 16 Sep 2019 12:08:07 -0400 Subject: RFR 8230870: Add a ZIP FS test that is similar to test/jdk/java/util/zip/EntryCount64k.java In-Reply-To: References: <89DF3E27-8A04-430B-B28D-DB2C23732BA2@oracle.com> Message-ID: <7EF90036-66BF-4B0C-930A-1FA0D9D77584@oracle.com> > On Sep 16, 2019, at 9:43 AM, Martin Buchholz wrote: > > Thanks for doing this. Thank you > Looks Good To Me, but as always I have some comments :-) Feedback always welcome as that is the only way to continue to get better and learn from others experience ;-) > > EntryCount64k was written before testng infrastructure was common. I might have done some surgery on EntryCount64k to accommodate zipfs instead of writing an entirely new test. zipfs adds to the number of ways that zip files can be written - I generally only thought about ZipOutputStream. One can structure zip tests using front-end/back-end strategy: Combine N ways to write a zip file with M ways to read it, and verify that they all work together. But we've never written tests that way. I had thought about reworking your original test but decided against it at this time as I wanted to keep the ZIP FS tests together. I will add it to my todo list to look at your suggestion. Right now I am more concerned on the added coverage and circling back later for consolidation > > Stop using System.currentTimeMillis for measuring elapsed time, and switch to System.nanoTime. Yes I know, old habits are hard to break and I was just looking for a ballpark with Mach5. I will switch it to nanoTime prior to pushing > Hmmm .... probably even better here is to hop over nanoTime to using java.time APIs like Duration.between as in https://www.baeldung.com/java-measure-elapsed-time section 3.2 > > On Wed, Sep 11, 2019 at 10:26 AM Lance Andersen > wrote: > Hi all, > > Please review the addition of a ZIP FS test which is similar to test/jdk/java/util/zip/EntryCount64k.java > > The test exercises the ZIP FS properties noCompression and forceZIP64End which we do not have much coverage for. > > The test runs clean Mach5 and and I run it 100 times each on windows-x64, macosx-x64, linux-x64 and linux-x64-open platforms to sanity check there are no potential timeout issues due to the test run > > I have left some basic timing methods in the test but have disabled them in the unlikely event we have to revisit a timeout issue. > > The webrev can be found at: http://cr.openjdk.java.net/~lancea/8230870/webrev.00/ > > Best > Lance > > > 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 > > > 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 lance.andersen at oracle.com Mon Sep 16 16:08:59 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Mon, 16 Sep 2019 12:08:59 -0400 Subject: RFR 8230870: Add a ZIP FS test that is similar to test/jdk/java/util/zip/EntryCount64k.java In-Reply-To: References: <89DF3E27-8A04-430B-B28D-DB2C23732BA2@oracle.com> Message-ID: Hi Christoph, Thank you! > On Sep 16, 2019, at 3:59 AM, Langer, Christoph wrote: > > Hi Lance, > > I looked at the test and also executed it and checked its output. Looks good to me, no comments ?? > > Best regards > Christoph > > From: nio-dev > On Behalf Of Lance Andersen > Sent: Mittwoch, 11. September 2019 19:23 > To: nio-dev > > Subject: RFR 8230870: Add a ZIP FS test that is similar to test/jdk/java/util/zip/EntryCount64k.java > > Hi all, > > Please review the addition of a ZIP FS test which is similar to test/jdk/java/util/zip/EntryCount64k.java > > The test exercises the ZIP FS properties noCompression and forceZIP64End which we do not have much coverage for. > > The test runs clean Mach5 and and I run it 100 times each on windows-x64, macosx-x64, linux-x64 and linux-x64-open platforms to sanity check there are no potential timeout issues due to the test run > > I have left some basic timing methods in the test but have disabled them in the unlikely event we have to revisit a timeout issue. > > The webrev can be found at: http://cr.openjdk.java.net/~lancea/8230870/webrev.00/ > > Best > Lance > > > 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 > > > > 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 Tue Sep 17 20:49:48 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 17 Sep 2019 13:49:48 -0700 Subject: 8231149: Small verbiage errors in java.nio.file package documentation Message-ID: <71D2A4AE-FA21-4A6B-ACAC-058DD6A3641F@oracle.com> https://bugs.openjdk.java.net/browse/JDK-8231149 A change to two sentences: @@ -34,7 +34,7 @@ * platform default provider, or to construct other provider implementations.

* *

Symbolic Links

- *

Many operating systems and file systems support for symbolic links. + *

Many operating systems and file systems support symbolic links. * A symbolic link is a special file that serves as a reference to another file. * For the most part, symbolic links are transparent to applications and * operations on symbolic links are automatically redirected to the target @@ -62,8 +62,8 @@ * to caching performed by the underlying operating system and delays induced by * network-filesystem protocols. This is true regardless of the language in which * these other programs are written, and whether they are running on the same machine - * or on some other machine. The exact nature of any such inconsistencies are - * system-dependent and are therefore unspecified.

+ * or on some other machine. The exact nature of any such inconsistencies is + * system-dependent and therefore unspecified.

* *

Synchronized I/O File Integrity

*

The {@link java.nio.file.StandardOpenOption#SYNC SYNC} and {@link This seems rather small to require a CSR. Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From lance.andersen at oracle.com Tue Sep 17 20:52:16 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Tue, 17 Sep 2019 16:52:16 -0400 Subject: 8231149: Small verbiage errors in java.nio.file package documentation In-Reply-To: <71D2A4AE-FA21-4A6B-ACAC-058DD6A3641F@oracle.com> References: <71D2A4AE-FA21-4A6B-ACAC-058DD6A3641F@oracle.com> Message-ID: Hi Brian > On Sep 17, 2019, at 4:49 PM, Brian Burkhalter wrote: > > https://bugs.openjdk.java.net/browse/JDK-8231149 > > A change to two sentences: > > @@ -34,7 +34,7 @@ > * platform default provider, or to construct other provider implementations.

> * > *

Symbolic Links

> - *

Many operating systems and file systems support for symbolic links. > + *

Many operating systems and file systems support symbolic links. > * A symbolic link is a special file that serves as a reference to another file. > * For the most part, symbolic links are transparent to applications and > * operations on symbolic links are automatically redirected to the target > > @@ -62,8 +62,8 @@ > * to caching performed by the underlying operating system and delays induced by > * network-filesystem protocols. This is true regardless of the language in which > * these other programs are written, and whether they are running on the same machine > - * or on some other machine. The exact nature of any such inconsistencies are > - * system-dependent and are therefore unspecified.

> + * or on some other machine. The exact nature of any such inconsistencies is should this still be ?inconsistencies are? ? > + * system-dependent and therefore unspecified.

> * > *

Synchronized I/O File Integrity

> *

The {@link java.nio.file.StandardOpenOption#SYNC SYNC} and {@link > > This seems rather small to require a CSR. agree > > 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 Tue Sep 17 20:54:09 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 17 Sep 2019 13:54:09 -0700 Subject: 8231149: Small verbiage errors in java.nio.file package documentation In-Reply-To: References: <71D2A4AE-FA21-4A6B-ACAC-058DD6A3641F@oracle.com> Message-ID: Hi Lance, > On Sep 17, 2019, at 1:52 PM, Lance Andersen wrote: > >> - * or on some other machine. The exact nature of any such inconsistencies are >> - * system-dependent and are therefore unspecified.

>> + * or on some other machine. The exact nature of any such inconsistencies is > should this still be ?inconsistencies are? ? I thought the conjugation of ?to be? was with respect to ?nature? as opposed to ?inconsistencies? hence the change to singular, but I could be mistaken. >> + * system-dependent and therefore unspecified.

>> * >> *

Synchronized I/O File Integrity

>> *

The {@link java.nio.file.StandardOpenOption#SYNC SYNC} and {@link >> >> This seems rather small to require a CSR. > > agree Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Tue Sep 17 21:02:17 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 17 Sep 2019 14:02:17 -0700 Subject: 8231149: Small verbiage errors in java.nio.file package documentation In-Reply-To: References: <71D2A4AE-FA21-4A6B-ACAC-058DD6A3641F@oracle.com> Message-ID: > On Sep 17, 2019, at 1:54 PM, Brian Burkhalter wrote: > >> On Sep 17, 2019, at 1:52 PM, Lance Andersen > wrote: >> >>> - * or on some other machine. The exact nature of any such inconsistencies are >>> - * system-dependent and are therefore unspecified.

>>> + * or on some other machine. The exact nature of any such inconsistencies is >> should this still be ?inconsistencies are? ? > > I thought the conjugation of ?to be? was with respect to ?nature? as opposed to ?inconsistencies? hence the change to singular, but I could be mistaken. Or maybe ?nature? should instead be plural: "The exact natures of any such inconsistencies are system-dependent and therefore unspecified." Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From lance.andersen at oracle.com Tue Sep 17 21:17:08 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Tue, 17 Sep 2019 17:17:08 -0400 Subject: 8231149: Small verbiage errors in java.nio.file package documentation In-Reply-To: References: <71D2A4AE-FA21-4A6B-ACAC-058DD6A3641F@oracle.com> Message-ID: > On Sep 17, 2019, at 4:54 PM, Brian Burkhalter wrote: > > Hi Lance, > >> On Sep 17, 2019, at 1:52 PM, Lance Andersen > wrote: >> >>> - * or on some other machine. The exact nature of any such inconsistencies are >>> - * system-dependent and are therefore unspecified.

>>> + * or on some other machine. The exact nature of any such inconsistencies is >> should this still be ?inconsistencies are? ? > > I thought the conjugation of ?to be? was with respect to ?nature? as opposed to ?inconsistencies? hence the change to singular, but I could be mistaken. > After a little googling this appears to be correct that is using ?is? vs ?are?. :-) So +1 >>> + * system-dependent and therefore unspecified.

>>> * >>> *

Synchronized I/O File Integrity

>>> *

The {@link java.nio.file.StandardOpenOption#SYNC SYNC} and {@link >>> >>> This seems rather small to require a CSR. >> >> agree > > 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 Alan.Bateman at oracle.com Wed Sep 18 06:19:43 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 18 Sep 2019 07:19:43 +0100 Subject: 8231149: Small verbiage errors in java.nio.file package documentation In-Reply-To: <71D2A4AE-FA21-4A6B-ACAC-058DD6A3641F@oracle.com> References: <71D2A4AE-FA21-4A6B-ACAC-058DD6A3641F@oracle.com> Message-ID: <6696cdb3-267f-7239-3ba9-ac37e968dcc8@oracle.com> On 17/09/2019 21:49, Brian Burkhalter wrote: > https://bugs.openjdk.java.net/browse/JDK-8231149 > > A change to two sentences: > > @@ -34,7 +34,7 @@ > * platform default provider, or to construct other provider > implementations.

> * > *

Symbolic Links

> - *

Many operating systems and file systems support for > symbolic links. > + *

Many operating systems and file systems support symbolic > links. I assume this should have been "have support for" (missing "have"). > * A symbolic link is a special file that serves as a reference to > another file. > * For the most part, symbolic links are transparent to applications and > * operations on symbolic links are automatically redirected to the > target > > @@ -62,8 +62,8 @@ > * to caching performed by the underlying operating system and delays > induced by > * network-filesystem protocols. This is true regardless of the > language in which > * these other programs are written, and whether they are running on > the same machine > - * or on some other machine.? The exact nature of any such > inconsistencies are > - * system-dependent and are therefore unspecified.

> + * or on some other machine.? The exact nature of any such > inconsistencies is > + * system-dependent and therefore unspecified.

That looks okay to me. -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Wed Sep 18 15:05:02 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 18 Sep 2019 08:05:02 -0700 Subject: 8231149: Small verbiage errors in java.nio.file package documentation In-Reply-To: <6696cdb3-267f-7239-3ba9-ac37e968dcc8@oracle.com> References: <71D2A4AE-FA21-4A6B-ACAC-058DD6A3641F@oracle.com> <6696cdb3-267f-7239-3ba9-ac37e968dcc8@oracle.com> Message-ID: <73316D7F-B94A-4342-B253-8842CF75BD96@oracle.com> > On Sep 17, 2019, at 11:19 PM, Alan Bateman wrote: > >> - *

Many operating systems and file systems support for symbolic links. >> + *

Many operating systems and file systems support symbolic links. > I assume this should have been "have support for" (missing "have"). I can change it to that. Either new way is better than the old. Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Wed Sep 18 18:24:37 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 18 Sep 2019 11:24:37 -0700 Subject: 8231149: Small verbiage errors in java.nio.file package documentation In-Reply-To: <73316D7F-B94A-4342-B253-8842CF75BD96@oracle.com> References: <71D2A4AE-FA21-4A6B-ACAC-058DD6A3641F@oracle.com> <6696cdb3-267f-7239-3ba9-ac37e968dcc8@oracle.com> <73316D7F-B94A-4342-B253-8842CF75BD96@oracle.com> Message-ID: <9ADF49E3-E5B2-4B15-8D1F-E996BB7D786C@oracle.com> > On Sep 18, 2019, at 8:05 AM, Brian Burkhalter wrote: > >> On Sep 17, 2019, at 11:19 PM, Alan Bateman > wrote: >> >>> - *

Many operating systems and file systems support for symbolic links. >>> + *

Many operating systems and file systems support symbolic links. >> I assume this should have been "have support for" (missing "have"). > > I can change it to that. Either new way is better than the old. Will push these changes unless there is an objection: - *

Many operating systems and file systems support for symbolic links. + *

Many operating systems and file systems have support for symbolic links. - * or on some other machine. The exact nature of any such inconsistencies are - * system-dependent and are therefore unspecified.

+ * or on some other machine. The exact nature of any such inconsistencies is + * system-dependent and therefore unspecified.

Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From vkempik at azul.com Thu Sep 19 09:48:32 2019 From: vkempik at azul.com (Vladimir Kempik) Date: Thu, 19 Sep 2019 09:48:32 +0000 Subject: RFR: 8229872: (fs) Increase buffer size used with getmntent In-Reply-To: References: <1DF90E8C-07FB-4809-A2AD-04D9D0F2FF0D@azul.com> <4840e25c-4794-22bb-bc62-d1103d1988a1@oracle.com> <11AAA5FB-BD27-4E20-B4D8-24CC9A99E017@azul.com> <179c534c-9a83-4a14-7023-fe332bdcdd8a@oracle.com> <24d7ea75-53d0-bd2e-0199-d2d0457a071d@oracle.com> <008017FD-4FEC-4E21-B73C-73AB8B3EBE93@azul.com> <87pnkdeac0.fsf@oldenburg2.str.redhat.com> <87h85l7jf8.fsf@oldenburg2.str.redhat.com> <3bd722e8-6290-60ff-af9f-d5d6a63f1218@oracle.com> <65c8cab4-09cc-d0ac-96eb-da9049d4d9b2@oracle.com> <41F66CCF-2A37-487C-BD6E-64052BA6C25A@azul.com> Message-ID: Hello any more opinions from anyone on the subject ? Thanks, Vladimir > 13 ????. 2019 ?., ? 14:58, Alan Bateman ???????(?): > > On 13/09/2019 12:32, Vladimir Kempik wrote: >> Hello >> just to make sure: after second review from smbd else, it should be pushed to http://hg.openjdk.java.net/jdk/jdk/, right? >> > The changes only requires one reviewer but since Florian took a close interest and was very helpful then I hope he will reply too. > > I checked the census and I see you have Committer role on the jdk-updates and jdk8u projects but not the jdk project. Is there someone in Azul that will sponsor/push this for you or do you want me to do it? > > -Alan. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From brian.burkhalter at oracle.com Thu Sep 19 15:32:55 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 19 Sep 2019 08:32:55 -0700 Subject: 8231254: (fs) Add test for macOS Catalina changes to protect system software Message-ID: https://bugs.openjdk.java.net/browse/JDK-8231254 http://cr.openjdk.java.net/~bpb/8231254/webrev.00/ This test verifies that ?/? is read-only and any existing directories in /usr/share/firmlinks are not. Probably testing other APIs on well known files in the read-only volume should be added as well. Thanks, Brian From brian.burkhalter at oracle.com Fri Sep 20 00:01:27 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 19 Sep 2019 17:01:27 -0700 Subject: 8231254: (fs) Add test for macOS Catalina changes to protect system software In-Reply-To: References: Message-ID: <92609911-E099-471A-8A69-5229030A4F6A@oracle.com> > On Sep 19, 2019, at 8:32 AM, Brian Burkhalter wrote: > > https://bugs.openjdk.java.net/browse/JDK-8231254 > http://cr.openjdk.java.net/~bpb/8231254/webrev.00/ > > This test verifies that ?/? is read-only and any existing directories in /usr/share/firmlinks are not. > > Probably testing other APIs on well known files in the read-only volume should be added as well. I added some other tests to check a smattering of NIO API calls applied to locations in both the system (read-only) and data (read-write) volumes. These are in the checkSystemVolume() and checkDataVolume() methods. http://cr.openjdk.java.net/~bpb/8231254/webrev.01/ Thanks, Brian From Alan.Bateman at oracle.com Fri Sep 20 09:27:09 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 20 Sep 2019 10:27:09 +0100 Subject: 8231254: (fs) Add test for macOS Catalina changes to protect system software In-Reply-To: <92609911-E099-471A-8A69-5229030A4F6A@oracle.com> References: <92609911-E099-471A-8A69-5229030A4F6A@oracle.com> Message-ID: On 20/09/2019 01:01, Brian Burkhalter wrote: > : > I added some other tests to check a smattering of NIO API calls applied to locations in both the system (read-only) and data (read-write) volumes. These are in the checkSystemVolume() and checkDataVolume() methods. > > http://cr.openjdk.java.net/~bpb/8231254/webrev.01/ The test is no longer a test for FileStore so it probably should be moved to a new location. The file/etc directory might be okay, maybe name it MacVolumesTest? In checkFirmLinks it would be better to replace L164-165 with Files.newBufferedReader(FIRMLINKS) and use try-with-resources to ensure that it closes the file. -Alan From michael.x.mcmahon at oracle.com Fri Sep 20 09:53:43 2019 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Fri, 20 Sep 2019 10:53:43 +0100 Subject: RFR 8231187: SelectorProvider.inheritedChannel() returns TCP socket channel for Unix domain socket Message-ID: <5D84A1A7.4020407@oracle.com> Hi, This issue was reported through a recent discussion proposing an API for Unix domain sockets. It fixes the current erroneous behavior where TCP type SocketChannels are returned and instead returns a Channel type which handles connected AF_UNIX sockets specifically. The fix also enables the whole inherited channel mechanism for Mac, which up to now has not been working. http://cr.openjdk.java.net/~michaelm/8231187/webrev.1/index.html Thanks, Michael. From Alan.Bateman at oracle.com Fri Sep 20 10:42:19 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 20 Sep 2019 11:42:19 +0100 Subject: RFR 8231187: SelectorProvider.inheritedChannel() returns TCP socket channel for Unix domain socket In-Reply-To: <5D84A1A7.4020407@oracle.com> References: <5D84A1A7.4020407@oracle.com> Message-ID: <24d7b2dd-56f3-aac5-abe7-d605507039d7@oracle.com> On 20/09/2019 10:53, Michael McMahon wrote: > Hi, > > This issue was reported through a recent discussion proposing an API > for Unix domain > sockets. It fixes the current erroneous behavior where TCP type > SocketChannels are returned > and instead returns a Channel type which handles connected AF_UNIX > sockets specifically. > > The fix also enables the whole inherited channel mechanism for Mac, > which up to now > has not been working. > > http://cr.openjdk.java.net/~michaelm/8231187/webrev.1/index.html Yes, I remember that bug came up in the proposal to add the API so it's good to get it fixed. I skimmed through the webrev. The async close doesn't look right, mostly missing preClose and the final close by the last thread doing I/O. The Unix implementation of SourceChannelImpl or SinkChannelImpl are the simplest examples to follow if you need it. The main issues are: - need a state field to track that the channel is closing - endRead need to close the channel when the state is_ST_CLOSING and there is no writer (the opposite for reader) - implCloseChannel should only close if reader and writer are both 0, otherwise it should preClose and signal the reader and/or writer. A minor nit is that getFDVal can be removed, and getFD can be private as the channel doesn't implement SelChImpl. As a precaultion, createChannel could return null if the address family is AF_UKNOWN. -Alan. From michael.x.mcmahon at oracle.com Fri Sep 20 10:56:48 2019 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Fri, 20 Sep 2019 11:56:48 +0100 Subject: RFR 8231187: SelectorProvider.inheritedChannel() returns TCP socket channel for Unix domain socket In-Reply-To: <24d7b2dd-56f3-aac5-abe7-d605507039d7@oracle.com> References: <5D84A1A7.4020407@oracle.com> <24d7b2dd-56f3-aac5-abe7-d605507039d7@oracle.com> Message-ID: <5D84B070.9020708@oracle.com> Hi Alan, On 20/09/2019, 11:42, Alan Bateman wrote: > On 20/09/2019 10:53, Michael McMahon wrote: >> Hi, >> >> This issue was reported through a recent discussion proposing an API >> for Unix domain >> sockets. It fixes the current erroneous behavior where TCP type >> SocketChannels are returned >> and instead returns a Channel type which handles connected AF_UNIX >> sockets specifically. >> >> The fix also enables the whole inherited channel mechanism for Mac, >> which up to now >> has not been working. >> >> http://cr.openjdk.java.net/~michaelm/8231187/webrev.1/index.html > Yes, I remember that bug came up in the proposal to add the API so > it's good to get it fixed. > > I skimmed through the webrev. The async close doesn't look right, > mostly missing preClose and the final close by the last thread doing > I/O. The Unix implementation of SourceChannelImpl or SinkChannelImpl > are the simplest examples to follow if you need it. The main issues are: > > - need a state field to track that the channel is closing > - endRead need to close the channel when the state is_ST_CLOSING and > there is no writer (the opposite for reader) > - implCloseChannel should only close if reader and writer are both 0, > otherwise it should preClose and signal the reader and/or writer. > Is the above not required only to allow draining of the socket when SO_LINGER is enabled, which is not supported in this case? > A minor nit is that getFDVal can be removed, and getFD can be private > as the channel doesn't implement SelChImpl. > OK > As a precaultion, createChannel could return null if the address > family is AF_UKNOWN. > OK Thanks, Michael. From lance.andersen at oracle.com Fri Sep 20 11:09:30 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Fri, 20 Sep 2019 07:09:30 -0400 Subject: RFR: 8231093: Document the ZIP FS properties noCompression and releaseVersion Message-ID: Hi all, Please review the fix for 8231093 which documents the ZIP FS properties ?noCompression" and ?releaseVersion?. The property ?multi-release? has been renamed to ?releaseVersion? as the supported property while ZIP FS still checks for ?multi-release? if ?releaseVersion? is not found. The webrev can be found at:http://cr.openjdk.java.net/~lancea/8231093/webrev.00/index.html . The CSR can be found at: https://bugs.openjdk.java.net/browse/JDK-8231248 It is important to note that there are additional ZIP FS properties that will remain undocumented/supportted at this time until we have adequate testing of the properties and determine if they add value to the developer community. Best, Lance 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 Alan.Bateman at oracle.com Fri Sep 20 12:20:06 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 20 Sep 2019 13:20:06 +0100 Subject: RFR 8231187: SelectorProvider.inheritedChannel() returns TCP socket channel for Unix domain socket In-Reply-To: <5D84B070.9020708@oracle.com> References: <5D84A1A7.4020407@oracle.com> <24d7b2dd-56f3-aac5-abe7-d605507039d7@oracle.com> <5D84B070.9020708@oracle.com> Message-ID: <840c694e-3b49-1c93-f638-ddf009ed1fa4@oracle.com> On 20/09/2019 11:56, Michael McMahon wrote: > > Is the above not required only to allow draining of the socket when > SO_LINGER is enabled, > which is not supported in this case? It's needed to coordinate closing with threads that are doing blocking I/O on the channel. SourceChannelImpl and SinkChannelImpl are good starting point because they are close to what you want, without all the additional details that SocketChannelImpl needs to be concerned with. -Alan From Alan.Bateman at oracle.com Fri Sep 20 13:53:23 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 20 Sep 2019 14:53:23 +0100 Subject: RFR: 8231093: Document the ZIP FS properties noCompression and releaseVersion In-Reply-To: References: Message-ID: On 20/09/2019 12:09, Lance Andersen wrote: > Hi all, > > Please review the fix for ?8231093 which documents the?ZIP FS > properties ?noCompression" and ?releaseVersion?. ?The property > ?multi-release? has been renamed to ?releaseVersion? as the supported > property while ZIP FS still checks for ??multi-release? if > ?releaseVersion? is not found. > > The webrev can be found > at:http://cr.openjdk.java.net/~lancea/8231093/webrev.00/index.html. > Do you need to update src/jdk.compiler/share/classes/com/sun/tools/javac/file/Locations.java to use the documented option? -Alan From brian.burkhalter at oracle.com Fri Sep 20 14:57:27 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 20 Sep 2019 07:57:27 -0700 Subject: 8231254: (fs) Add test for macOS Catalina changes to protect system software In-Reply-To: References: <92609911-E099-471A-8A69-5229030A4F6A@oracle.com> Message-ID: <24870883-399D-4A91-B11C-3FCA99D70024@oracle.com> > On Sep 20, 2019, at 2:27 AM, Alan Bateman wrote: > > On 20/09/2019 01:01, Brian Burkhalter wrote: >> : >> I added some other tests to check a smattering of NIO API calls applied to locations in both the system (read-only) and data (read-write) volumes. These are in the checkSystemVolume() and checkDataVolume() methods. >> >> http://cr.openjdk.java.net/~bpb/8231254/webrev.01/ > The test is no longer a test for FileStore so it probably should be moved to a new location. The file/etc directory might be okay, maybe name it MacVolumesTest? > > In checkFirmLinks it would be better to replace L164-165 with Files.newBufferedReader(FIRMLINKS) and use try-with-resources to ensure that it closes the file. OK I will make the above changes but not until I have access to a Catalina machine again. Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From martinrb at google.com Fri Sep 20 15:54:31 2019 From: martinrb at google.com (Martin Buchholz) Date: Fri, 20 Sep 2019 08:54:31 -0700 Subject: RFR: 8231093: Document the ZIP FS properties noCompression and releaseVersion In-Reply-To: References: Message-ID: Thanks. When we document these properties, we should make it clearer what the default behavior is, e.g. what happens if a multi-release jar is used and releaseVersion is unspecified. It's unfortunate that we have (at least) 3 different parallel APIs for jar creation - the jar CLI, system properties for zipfs and java methods for ZipOutputStream. Looking at https://download.java.net/java/early_access/jdk14/docs/api/java.base/java/util/zip/ZipOutputStream.html#setMethod(int) I can see different terminology "set METHOD to DEFLATED" rather than set a "noCompression" bit. Hopefully someday we will add support for other compression methods (PKWARE supports many more) and then having only a boolean will look poorly planned. Maybe instead "compressionMethod" with current values "STORED" "DEFLATED". https://pkware.cachefly.net/webdocs/casestudies/APPNOTE.TXT 4.4.5 compression method: (2 bytes) 0 - The file is stored (no compression) 1 - The file is Shrunk 2 - The file is Reduced with compression factor 1 3 - The file is Reduced with compression factor 2 4 - The file is Reduced with compression factor 3 5 - The file is Reduced with compression factor 4 6 - The file is Imploded 7 - Reserved for Tokenizing compression algorithm 8 - The file is Deflated 9 - Enhanced Deflating using Deflate64(tm) 10 - PKWARE Data Compression Library Imploding (old IBM TERSE) 11 - Reserved by PKWARE 12 - File is compressed using BZIP2 algorithm 13 - Reserved by PKWARE 14 - LZMA 15 - Reserved by PKWARE 16 - IBM z/OS CMPSC Compression 17 - Reserved by PKWARE 18 - File is compressed using IBM TERSE (new) 19 - IBM LZ77 z Architecture (PFS) 96 - JPEG variant 97 - WavPack compressed data 98 - PPMd version I, Rev 1 99 - AE-x encryption marker (see APPENDIX E) On Fri, Sep 20, 2019 at 4:10 AM Lance Andersen wrote: > Hi all, > > Please review the fix for 8231093 which documents the ZIP FS properties > ?noCompression" and ?releaseVersion?. The property ?multi-release? has > been renamed to ?releaseVersion? as the supported property while ZIP FS > still checks for ?multi-release? if ?releaseVersion? is not found. > > The webrev can be found at: > http://cr.openjdk.java.net/~lancea/8231093/webrev.00/index.html. > > The CSR can be found at: https://bugs.openjdk.java.net/browse/JDK-8231248 > > It is important to note that there are additional ZIP FS properties that > will remain undocumented/supportted at this time until we have adequate > testing of the properties and determine if they add value to the developer > community. > > Best, > Lance > > > > > Lance Andersen| > Principal Member of Technical Staff | +1.781.442.2037 <(781)%20442-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 Alan.Bateman at oracle.com Fri Sep 20 16:02:45 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 20 Sep 2019 17:02:45 +0100 Subject: RFR: 8231093: Document the ZIP FS properties noCompression and releaseVersion In-Reply-To: References: Message-ID: On 20/09/2019 16:54, Martin Buchholz wrote: > Thanks. > > When we document these properties, we should make it clearer what the > default behavior is, e.g. what happens if a multi-release jar is used > and releaseVersion is unspecified. The table of properties that we've started to build up in the JDK 14 builds has a column for the default value so hopefully the defaults will be clear. Also the description for "releaseVersion" has proposed text to say that the JAR file will be considered unversioned when the property is not specified, maybe you are saying that wording needed to be improved? I agree the noCompression property should be examined to allow for other potential compression methods. -Alan From lance.andersen at oracle.com Fri Sep 20 16:53:39 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Fri, 20 Sep 2019 12:53:39 -0400 Subject: RFR: 8231093: Document the ZIP FS properties noCompression and releaseVersion In-Reply-To: References: Message-ID: <4F51B399-CDA4-478D-B70B-EE5B6FC31144@oracle.com> > On Sep 20, 2019, at 9:53 AM, Alan Bateman wrote: > > On 20/09/2019 12:09, Lance Andersen wrote: >> Hi all, >> >> Please review the fix for 8231093 which documents the ZIP FS properties ?noCompression" and ?releaseVersion?. The property ?multi-release? has been renamed to ?releaseVersion? as the supported property while ZIP FS still checks for ?multi-release? if ?releaseVersion? is not found. >> >> The webrev can be found at:http://cr.openjdk.java.net/~lancea/8231093/webrev.00/index.html. >> > Do you need to update src/jdk.compiler/share/classes/com/sun/tools/javac/file/Locations.java to use the documented option? I will update this to use the new property name. Best Lance > > -Alan 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 martinrb at google.com Fri Sep 20 16:59:17 2019 From: martinrb at google.com (Martin Buchholz) Date: Fri, 20 Sep 2019 09:59:17 -0700 Subject: RFR: 8231093: Document the ZIP FS properties noCompression and releaseVersion In-Reply-To: References: Message-ID: On Fri, Sep 20, 2019 at 9:02 AM Alan Bateman wrote: > On 20/09/2019 16:54, Martin Buchholz wrote: > > Thanks. > > > > When we document these properties, we should make it clearer what the > > default behavior is, e.g. what happens if a multi-release jar is used > > and releaseVersion is unspecified. > The table of properties that we've started to build up in the JDK 14 > builds has a column for the default value so hopefully the defaults will > be clear. Right - I missed that. I read https://download.java.net/java/early_access/jdk14/docs/api/jdk.zipfs/module-summary.html and I now see I also confused "system properties" with "file system properties" > Also the description for "releaseVersion" has proposed text to > say that the JAR file will be considered unversioned when the property > is not specified, maybe you are saying that wording needed to be improved? > I re-read the proposed spec for releaseVersion, and I don't see where it says that. A very pedantic reading is that the default value is null, which does not represent a valid version number, so the default behavior should be to throw IllegalArgumentException ?! > > > I agree the noCompression property should be examined to allow for other > potential compression methods. > > -Alan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lance.andersen at oracle.com Fri Sep 20 17:17:53 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Fri, 20 Sep 2019 13:17:53 -0400 Subject: RFR: 8231093: Document the ZIP FS properties noCompression and releaseVersion In-Reply-To: References: Message-ID: <8011ADA5-68A0-47D3-9D11-A53DCDCA0C11@oracle.com> > On Sep 20, 2019, at 12:59 PM, Martin Buchholz wrote: > > > > On Fri, Sep 20, 2019 at 9:02 AM Alan Bateman > wrote: > On 20/09/2019 16:54, Martin Buchholz wrote: > > Thanks. > > > > When we document these properties, we should make it clearer what the > > default behavior is, e.g. what happens if a multi-release jar is used > > and releaseVersion is unspecified. > The table of properties that we've started to build up in the JDK 14 > builds has a column for the default value so hopefully the defaults will > be clear. > > Right - I missed that. I read > https://download.java.net/java/early_access/jdk14/docs/api/jdk.zipfs/module-summary.html > and I now see I also confused "system properties" with "file system properties" > > Also the description for "releaseVersion" has proposed text to > say that the JAR file will be considered unversioned when the property > is not specified, maybe you are saying that wording needed to be improved? > > I re-read the proposed spec for releaseVersion, and I don't see where it says that. A very pedantic reading is that the default value is null, which does not represent a valid version number, so the default behavior should be to throw IllegalArgumentException ?! I can add a sentence that says if releaseVersion is not set and a multi-release JAR accessed via the ZIP FS, the JAR will be treated as an un-versioned JAR > > > I agree the noCompression property should be examined to allow for other > potential compression methods. > Alan and I talked off-line. I will add a compressionMode Property which will currently accept the strings: STORED or DEFLATED which will take precedence over the noCompression property which we will leave undocumented. > -Alan 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 martinrb at google.com Fri Sep 20 17:43:49 2019 From: martinrb at google.com (Martin Buchholz) Date: Fri, 20 Sep 2019 10:43:49 -0700 Subject: RFR: 8231093: Document the ZIP FS properties noCompression and releaseVersion In-Reply-To: <8011ADA5-68A0-47D3-9D11-A53DCDCA0C11@oracle.com> References: <8011ADA5-68A0-47D3-9D11-A53DCDCA0C11@oracle.com> Message-ID: On Fri, Sep 20, 2019 at 10:18 AM Lance Andersen wrote: > > On Sep 20, 2019, at 12:59 PM, Martin Buchholz wrote: > > > > On Fri, Sep 20, 2019 at 9:02 AM Alan Bateman > wrote: > >> On 20/09/2019 16:54, Martin Buchholz wrote: >> > Thanks. >> > >> > When we document these properties, we should make it clearer what the >> > default behavior is, e.g. what happens if a multi-release jar is used >> > and releaseVersion is unspecified. >> The table of properties that we've started to build up in the JDK 14 >> builds has a column for the default value so hopefully the defaults will >> be clear. > > > Right - I missed that. I read > > https://download.java.net/java/early_access/jdk14/docs/api/jdk.zipfs/module-summary.html > and I now see I also confused "system properties" with "file system > properties" > > >> Also the description for "releaseVersion" has proposed text to >> say that the JAR file will be considered unversioned when the property >> is not specified, maybe you are saying that wording needed to be improved? >> > > I re-read the proposed spec for releaseVersion, and I don't see where it > says that. A very pedantic reading is that the default value is null, > which does not represent a valid version number, so the default behavior > should be to throw IllegalArgumentException ?! > > > I can add a sentence that says if releaseVersion is not set and a > multi-release JAR accessed via the ZIP FS, the JAR will be treated as an > un-versioned JAR > More simply? "If the property is null or unset, then the JAR will be treated as an un-versioned JAR." (do we make sure an explicit null is actually accepted?) > I agree the noCompression property should be examined to allow for other >> potential compression methods. >> >> > Alan and I talked off-line. I will add a compressionMode Property which > will currently accept the strings: STORED or DEFLATED which will take > precedence over the noCompression property which we will leave > undocumented. > Thanks! Consistency demands we name it "method" not "mode" -------------- 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 Fri Sep 20 18:40:44 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 20 Sep 2019 11:40:44 -0700 Subject: 8231174: (fs) FileTime should have 100ns resolution (win) Message-ID: https://bugs.openjdk.java.net/browse/JDK-8231174 http://cr.openjdk.java.net/~bpb/8231174/webrev.00/ Change the file timestamp resolution on Windows from microseconds to intervals of 100 nanoseconds. Only systems where the working directory is NTFS are currently verified by the test. Thanks, Brian From brian.burkhalter at oracle.com Fri Sep 20 19:14:07 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 20 Sep 2019 12:14:07 -0700 Subject: 8231254: (fs) Add test for macOS Catalina changes to protect system software In-Reply-To: <24870883-399D-4A91-B11C-3FCA99D70024@oracle.com> References: <92609911-E099-471A-8A69-5229030A4F6A@oracle.com> <24870883-399D-4A91-B11C-3FCA99D70024@oracle.com> Message-ID: <6015D84D-3394-4ED0-AE95-41065BBFF784@oracle.com> > On Sep 20, 2019, at 7:57 AM, Brian Burkhalter wrote: > > >> On Sep 20, 2019, at 2:27 AM, Alan Bateman > wrote: >> >> On 20/09/2019 01:01, Brian Burkhalter wrote: >>> : >>> I added some other tests to check a smattering of NIO API calls applied to locations in both the system (read-only) and data (read-write) volumes. These are in the checkSystemVolume() and checkDataVolume() methods. >>> >>> http://cr.openjdk.java.net/~bpb/8231254/webrev.01/ >> The test is no longer a test for FileStore so it probably should be moved to a new location. The file/etc directory might be okay, maybe name it MacVolumesTest? >> >> In checkFirmLinks it would be better to replace L164-165 with Files.newBufferedReader(FIRMLINKS) and use try-with-resources to ensure that it closes the file. > > OK I will make the above changes but not until I have access to a Catalina machine again. The suggested changes are made in http://cr.openjdk.java.net/~bpb/8231254/webrev.02/. Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Fri Sep 20 19:44:26 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 20 Sep 2019 20:44:26 +0100 Subject: 8231174: (fs) FileTime should have 100ns resolution (win) In-Reply-To: References: Message-ID: <04c79988-3949-6b70-d676-b9bf64caab28@oracle.com> On 20/09/2019 19:40, Brian Burkhalter wrote: > https://bugs.openjdk.java.net/browse/JDK-8231174 > http://cr.openjdk.java.net/~bpb/8231174/webrev.00/ > > Change the file timestamp resolution on Windows from microseconds to intervals of 100 nanoseconds. Only systems where the working directory is NTFS are currently verified by the test. > This changes the implementation to use BigInteger in the conversion from long <--> FileTime which seems a bit overkill. I think we should explore other alternatives before going that route. -Alan From brian.burkhalter at oracle.com Fri Sep 20 19:46:33 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 20 Sep 2019 12:46:33 -0700 Subject: 8231254: (fs) Add test for macOS Catalina changes to protect system software In-Reply-To: <3a9eb988-cc03-a687-a414-931b60bb9591@oracle.com> References: <92609911-E099-471A-8A69-5229030A4F6A@oracle.com> <24870883-399D-4A91-B11C-3FCA99D70024@oracle.com> <6015D84D-3394-4ED0-AE95-41065BBFF784@oracle.com> <3a9eb988-cc03-a687-a414-931b60bb9591@oracle.com> Message-ID: > On Sep 20, 2019, at 12:45 PM, Alan Bateman wrote: > > On 20/09/2019 20:14, Brian Burkhalter wrote: >> The suggested changes are made in http://cr.openjdk.java.net/~bpb/8231254/webrev.02/ . >> > This looks okay to me. Thanks for the quick review. I?ll withhold pushing it until I can actually run it again on Catalina. Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Fri Sep 20 19:45:34 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 20 Sep 2019 20:45:34 +0100 Subject: 8231254: (fs) Add test for macOS Catalina changes to protect system software In-Reply-To: <6015D84D-3394-4ED0-AE95-41065BBFF784@oracle.com> References: <92609911-E099-471A-8A69-5229030A4F6A@oracle.com> <24870883-399D-4A91-B11C-3FCA99D70024@oracle.com> <6015D84D-3394-4ED0-AE95-41065BBFF784@oracle.com> Message-ID: <3a9eb988-cc03-a687-a414-931b60bb9591@oracle.com> On 20/09/2019 20:14, Brian Burkhalter wrote: > The suggested changes are made in > http://cr.openjdk.java.net/~bpb/8231254/webrev.02/. > This looks okay to me. -Alan From brian.burkhalter at oracle.com Fri Sep 20 22:16:27 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 20 Sep 2019 15:16:27 -0700 Subject: 8231174: (fs) FileTime should have 100ns resolution (win) In-Reply-To: <04c79988-3949-6b70-d676-b9bf64caab28@oracle.com> References: <04c79988-3949-6b70-d676-b9bf64caab28@oracle.com> Message-ID: > On Sep 20, 2019, at 12:44 PM, Alan Bateman wrote: > > On 20/09/2019 19:40, Brian Burkhalter wrote: >> https://bugs.openjdk.java.net/browse/JDK-8231174 >> http://cr.openjdk.java.net/~bpb/8231174/webrev.00/ >> >> Change the file timestamp resolution on Windows from microseconds to intervals of 100 nanoseconds. Only systems where the working directory is NTFS are currently verified by the test. >> > This changes the implementation to use BigInteger in the conversion from long <--> FileTime which seems a bit overkill. I think we should explore other alternatives before going that route. I?ve eliminated the use of BigInteger in this patch: http://cr.openjdk.java.net/~bpb/8231174/webrev.01/. I verified that toWindowsTime(FileTime.from(Long.MAX_VALUE, TimeUnit.NANOSECONDS)) does not overflow and that toFileTime(toWindowsTime(FileTime.from(Long.MAX_VALUE, TimeUnit.NANOSECONDS))) does not overflow and returns 100*(Long.MAX_VALUE/100) as one would expect. The value Long.MAX_VALUE nanoseconds represents about 292 years. Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Sun Sep 22 17:37:39 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 22 Sep 2019 18:37:39 +0100 Subject: 8231174: (fs) FileTime should have 100ns resolution (win) In-Reply-To: References: <04c79988-3949-6b70-d676-b9bf64caab28@oracle.com> Message-ID: <5c4c1c13-c859-c9ac-6dd1-6b2d4dd78fb9@oracle.com> On 20/09/2019 23:16, Brian Burkhalter wrote: > : > > I?ve eliminated the use of BigInteger in this patch: > http://cr.openjdk.java.net/~bpb/8231174/webrev.01/. > > I verified that > > toWindowsTime(FileTime.from(Long.MAX_VALUE, TimeUnit.NANOSECONDS)) > > does not overflow and that > > toFileTime(toWindowsTime(FileTime.from(Long.MAX_VALUE, > TimeUnit.NANOSECONDS))) > > does not overflow and returns 100*(Long.MAX_VALUE/100) as one would > expect. The value Long.MAX_VALUE nanoseconds represents about 292 years. > The Windows time stamps are 64-bit so my concern is that toFileTime will convert from 100ns intervals to nanos and overflow. So I suspect an overflow check is needed there. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From lance.andersen at oracle.com Sun Sep 22 22:43:20 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Sun, 22 Sep 2019 18:43:20 -0400 Subject: RFR: 8231093: Document the ZIP FS properties noCompression and releaseVersion In-Reply-To: References: <8011ADA5-68A0-47D3-9D11-A53DCDCA0C11@oracle.com> Message-ID: I updated the patch and the CSR. The updated webrev is: http://cr.openjdk.java.net/~lancea/8231093/webrev.01/index.html > On Sep 20, 2019, at 1:43 PM, Martin Buchholz wrote: > > > > On Fri, Sep 20, 2019 at 10:18 AM Lance Andersen > wrote: > >> On Sep 20, 2019, at 12:59 PM, Martin Buchholz > wrote: >> >> >> >> On Fri, Sep 20, 2019 at 9:02 AM Alan Bateman > wrote: >> On 20/09/2019 16:54, Martin Buchholz wrote: >> > Thanks. >> > >> > When we document these properties, we should make it clearer what the >> > default behavior is, e.g. what happens if a multi-release jar is used >> > and releaseVersion is unspecified. >> The table of properties that we've started to build up in the JDK 14 >> builds has a column for the default value so hopefully the defaults will >> be clear. >> >> Right - I missed that. I read >> https://download.java.net/java/early_access/jdk14/docs/api/jdk.zipfs/module-summary.html >> and I now see I also confused "system properties" with "file system properties" >> >> Also the description for "releaseVersion" has proposed text to >> say that the JAR file will be considered unversioned when the property >> is not specified, maybe you are saying that wording needed to be improved? >> >> I re-read the proposed spec for releaseVersion, and I don't see where it says that. A very pedantic reading is that the default value is null, which does not represent a valid version number, so the default behavior should be to throw IllegalArgumentException ?! > > I can add a sentence that says if releaseVersion is not set and a multi-release JAR accessed via the ZIP FS, the JAR will be treated as an un-versioned JAR > > More simply? > "If the property is null or unset, then the JAR will be treated as an un-versioned JAR." > (do we make sure an explicit null is actually accepted?) > >> I agree the noCompression property should be examined to allow for other >> potential compression methods. >> > > Alan and I talked off-line. I will add a compressionMode Property which will currently accept the strings: STORED or DEFLATED which will take precedence over the noCompression property which we will leave undocumented. > > Thanks! Consistency demands we name it "method" not ?mode" Agree and that is what I meant to do originally, the brain however thought otherwise ;-) > > 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 franta-java at frantovo.cz Mon Sep 23 14:20:25 2019 From: franta-java at frantovo.cz (=?UTF-8?B?RnJhbnRpxaFlayBLdcSNZXJh?=) Date: Mon, 23 Sep 2019 16:20:25 +0200 Subject: Unix domain sockets (UDS, AF_UNIX) in System.inheritedChannel() and elsewhere in Java + [JDK-8231187] + [JDK-8231358] In-Reply-To: References: <5e31f8ab-9007-a501-1704-935e79f0133f@frantovo.cz> <4b57b5c2-afea-3ea9-73e2-0e3913ca6ef7@oracle.com> <0aa6e746-0a29-53ba-27dd-e36ad71e3b26@frantovo.cz> <75b60535-ab55-2e3c-d283-a36b78e4175c@frantovo.cz> <85cf2869-4fa6-a246-d8f5-ce56890f37ad@oracle.com> Message-ID: In response to: and > Best to ask Franti?ek to argue his approach on nio-dev. The concern with his approach is that it converts the local/remote address to an IPv4 address, makes it looks like the socket is bound or connect to the wildcard address. Would be the 127.0.0.1 better? However I agree that this is not optimal (this was intended as a hotfix changing minimum amount of code). > More generally, ServerSocketChannel and SocketChannel aren't appropriate channels to return because of the specified socket options and half close semantics. It would require specification changes to allow ServerSocketChannel and SocketChannel be channels for other types of listener and stream-oriented channels. I have successfully tested it with Jetty and Tomcat ? they were able to listen on an inherited unix domain socket (I can connect to them e.g. using the socat command or Apache HTTPD configured as a reverse proxy). But again, I agree that using inet channels for other than inet connections is bad. This was the reason why I suggested adding real support for unix domain sockets: . I wish unix domain sockets became first class citizens in Java (the channel and address interfaces are generic enough and prepared for such extension). > This bug needs to be fixed independent of any future work to define new channel types for Unix domain. Agree, but please fix it in a backward compatible way. > Would be useful to support a public API to AF_UNIX socket channels for both connection sockets and listeners. Also, provide hook into SelectorProvider.inheritedChannel. Agree. > Need to verify support in Windows, whether the new AF_UNIX sockets can be multiplexed with existing networking sockets Latest Windows versions have support for AF_UNIX, but they will probably require different native C code than the network sockets (while on unix systems the C code is almost the same). Franta From michael.x.mcmahon at oracle.com Mon Sep 23 14:47:45 2019 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Mon, 23 Sep 2019 15:47:45 +0100 Subject: Unix domain sockets (UDS, AF_UNIX) in System.inheritedChannel() and elsewhere in Java + [JDK-8231187] + [JDK-8231358] In-Reply-To: References: <5e31f8ab-9007-a501-1704-935e79f0133f@frantovo.cz> <4b57b5c2-afea-3ea9-73e2-0e3913ca6ef7@oracle.com> <0aa6e746-0a29-53ba-27dd-e36ad71e3b26@frantovo.cz> <75b60535-ab55-2e3c-d283-a36b78e4175c@frantovo.cz> <85cf2869-4fa6-a246-d8f5-ce56890f37ad@oracle.com> Message-ID: <5D88DB11.10307@oracle.com> Hi Franta, I have filed https://bugs.openjdk.java.net/browse/JDK-8231358 to cover the general case of support for UNIX domain sockets. I think we should fix this bug independent of that though. The test case you supplied incl. native launcher was useful for this. So, thanks for that. The change proposed here doesn't preclude any future work in this area. I'll be updating my webrev shortly after Alan's comments from Friday. - Michael. On 23/09/2019, 15:20, Franti?ek Ku?era wrote: > In response to: and > > > > Best to ask Franti?ek to argue his approach on nio-dev. The concern > with his approach is that it converts the local/remote address to an > IPv4 address, makes it looks like the socket is bound or connect to > the wildcard address. > > Would be the 127.0.0.1 better? However I agree that this is not > optimal (this was intended as a hotfix changing minimum amount of code). > > > More generally, ServerSocketChannel and SocketChannel aren't > appropriate channels to return because of the specified socket options > and half close semantics. It would require specification changes to > allow ServerSocketChannel and SocketChannel be channels for other > types of listener and stream-oriented channels. > > I have successfully tested it with Jetty and Tomcat ? they were able > to listen on an inherited unix domain socket (I can connect to them > e.g. using the socat command or Apache HTTPD configured as a reverse > proxy). > > But again, I agree that using inet channels for other than inet > connections is bad. This was the reason why I suggested adding real > support for unix domain sockets: > . > I wish unix domain sockets became first class citizens in Java (the > channel and address interfaces are generic enough and prepared for > such extension). > > > This bug needs to be fixed independent of any future work to define > new channel types for Unix domain. > > Agree, but please fix it in a backward compatible way. > > > Would be useful to support a public API to AF_UNIX socket channels > for both connection sockets and listeners. Also, provide hook into > SelectorProvider.inheritedChannel. > > Agree. > > > Need to verify support in Windows, whether the new AF_UNIX sockets > can be multiplexed with existing networking sockets > > Latest Windows versions have support for AF_UNIX, but they will > probably require different native C code than the network sockets > (while on unix systems the C code is almost the same). > > Franta > From michael.x.mcmahon at oracle.com Mon Sep 23 16:56:35 2019 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Mon, 23 Sep 2019 17:56:35 +0100 Subject: RFR 8231187: SelectorProvider.inheritedChannel() returns TCP socket channel for Unix domain socket In-Reply-To: <840c694e-3b49-1c93-f638-ddf009ed1fa4@oracle.com> References: <5D84A1A7.4020407@oracle.com> <24d7b2dd-56f3-aac5-abe7-d605507039d7@oracle.com> <5D84B070.9020708@oracle.com> <840c694e-3b49-1c93-f638-ddf009ed1fa4@oracle.com> Message-ID: <5D88F943.4010604@oracle.com> Okay, I see the reason for it now. It is the potential race when closing a socket and its file descriptor possibly being reassigned to another opened file, at the same time as another thread starting an I/O operation on the original socket. I have added the two stage close logic similar to SocketChannel and the Source/SinkChannels you mentioned. Updated webrev at: http://cr.openjdk.java.net/~michaelm/8231187/webrev.2/index.html Thanks, Michael. On 20/09/2019, 13:20, Alan Bateman wrote: > On 20/09/2019 11:56, Michael McMahon wrote: >> >> Is the above not required only to allow draining of the socket when >> SO_LINGER is enabled, >> which is not supported in this case? > It's needed to coordinate closing with threads that are doing blocking > I/O on the channel. SourceChannelImpl and SinkChannelImpl are good > starting point because they are close to what you want, without all > the additional details that SocketChannelImpl needs to be concerned with. > > -Alan From Alan.Bateman at oracle.com Mon Sep 23 17:32:28 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 23 Sep 2019 18:32:28 +0100 Subject: RFR 8231187: SelectorProvider.inheritedChannel() returns TCP socket channel for Unix domain socket In-Reply-To: <5D88F943.4010604@oracle.com> References: <5D84A1A7.4020407@oracle.com> <24d7b2dd-56f3-aac5-abe7-d605507039d7@oracle.com> <5D84B070.9020708@oracle.com> <840c694e-3b49-1c93-f638-ddf009ed1fa4@oracle.com> <5D88F943.4010604@oracle.com> Message-ID: <3f4f20a5-88d7-f939-2b0b-2a1ed3478a76@oracle.com> On 23/09/2019 17:56, Michael McMahon wrote: > Okay, I see the reason for it now. It is the potential race when > closing a socket > and its file descriptor possibly being reassigned to another opened > file, at the same time > as another thread starting an I/O operation on the original socket. > > I have added the two stage close logic similar to SocketChannel and > the Source/SinkChannels you > mentioned. > > Updated webrev at: > http://cr.openjdk.java.net/~michaelm/8231187/webrev.2/index.html UnixDomainSocketImpl looks right now, trivially you can drop fdVal as that shouldn't be needed. Did you consider the comment to return null when addressFamily is AF_UNKNOWN? -Alan From michael.x.mcmahon at oracle.com Mon Sep 23 18:04:32 2019 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Mon, 23 Sep 2019 19:04:32 +0100 Subject: RFR 8231187: SelectorProvider.inheritedChannel() returns TCP socket channel for Unix domain socket In-Reply-To: <3f4f20a5-88d7-f939-2b0b-2a1ed3478a76@oracle.com> References: <5D84A1A7.4020407@oracle.com> <24d7b2dd-56f3-aac5-abe7-d605507039d7@oracle.com> <5D84B070.9020708@oracle.com> <840c694e-3b49-1c93-f638-ddf009ed1fa4@oracle.com> <5D88F943.4010604@oracle.com> <3f4f20a5-88d7-f939-2b0b-2a1ed3478a76@oracle.com> Message-ID: <5D890930.9040503@oracle.com> On 23/09/2019, 18:32, Alan Bateman wrote: > On 23/09/2019 17:56, Michael McMahon wrote: >> Okay, I see the reason for it now. It is the potential race when >> closing a socket >> and its file descriptor possibly being reassigned to another opened >> file, at the same time >> as another thread starting an I/O operation on the original socket. >> >> I have added the two stage close logic similar to SocketChannel and >> the Source/SinkChannels you >> mentioned. >> >> Updated webrev at: >> http://cr.openjdk.java.net/~michaelm/8231187/webrev.2/index.html > UnixDomainSocketImpl looks right now, trivially you can drop fdVal as > that shouldn't be needed. > > Did you consider the comment to return null when addressFamily is > AF_UNKNOWN? > I've just updated the webrev in place with those changes. Thanks, Michael. > -Alan From Alan.Bateman at oracle.com Mon Sep 23 18:32:56 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 23 Sep 2019 19:32:56 +0100 Subject: RFR: 8231093: Document the ZIP FS properties noCompression and releaseVersion In-Reply-To: References: <8011ADA5-68A0-47D3-9D11-A53DCDCA0C11@oracle.com> Message-ID: On 22/09/2019 23:43, Lance Andersen wrote: > I updated the patch and the CSR. > > The updated webrev is: > http://cr.openjdk.java.net/~lancea/8231093/webrev.01/index.html > I went through the spec updates in module-info.java. "when adding entries ...". Is that also true when someone re-writes a file? Do we need quotes around "STORED" and "DEFLATED"? value to make it clearer that they are strings? "an IllegalArgumentException will be thrown". This could be expanded to say that will be thrown when creating the file system. For releaseVersion there are 3 list items that start "If the value ..." and one that starts with "If the Object". We should keep the wording consistent. Also it feels like it accepts too many possible value types and maybe some of these should be dropped. Could we link "multi-release JAR" to the "Multi-release JAR files" section of the JAR file spec. I think {@docRoot}/../specs/jar/jar.html should work. When the value of releaseVersion is a String or Integer then it's the feature version.? In MR JARs the version is the major version of the Java platform release so "11.0.1" shouldn't be in the example. The paragraph for a value of "runtime" or Runtime.Version is a bit difficult to read. I think you want "runtime" to use Runtime.version().feature(). If a Runtime.Version object is provided then it's feature() method will be invoked. Maybe it would be better to split these out or maybe allowing a Runtime.Version object should be dropped to reduce the number of possible value types. -Alan From brian.burkhalter at oracle.com Mon Sep 23 19:13:08 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 23 Sep 2019 12:13:08 -0700 Subject: 8231174: (fs) FileTime should have 100ns resolution (win) In-Reply-To: <5c4c1c13-c859-c9ac-6dd1-6b2d4dd78fb9@oracle.com> References: <04c79988-3949-6b70-d676-b9bf64caab28@oracle.com> <5c4c1c13-c859-c9ac-6dd1-6b2d4dd78fb9@oracle.com> Message-ID: <8A4EBD48-4D54-4723-8EBC-2C09443EAB18@oracle.com> > On Sep 22, 2019, at 10:37 AM, Alan Bateman wrote: > >> The value Long.MAX_VALUE nanoseconds represents about 292 years. >> > The Windows time stamps are 64-bit so my concern is that toFileTime will convert from 100ns intervals to nanos and overflow. So I suspect an overflow check is needed there. I think that this version [1,2] should address the concern. Thanks, Brian [1] diff --- a/src/java.base/windows/classes/sun/nio/fs/WindowsFileAttributes.java +++ b/src/java.base/windows/classes/sun/nio/fs/WindowsFileAttributes.java @@ -139,9 +139,16 @@ static FileTime toFileTime(long time) { // adjust to java epoch retaining 100ns precision time += WINDOWS_EPOCH_IN_100NS; - // 100ns -> ns - time *= 100L; - return FileTime.from(time, TimeUnit.NANOSECONDS); + try { + // 100ns -> ns + time = Math.multiplyExact(time, 100L); + return FileTime.from(time, TimeUnit.NANOSECONDS); + } catch (ArithmeticException e) { + // on overflow, fall back to lower precision + // 100ns -> us + time /= 10L; + return FileTime.from(time, TimeUnit.MICROSECONDS); + } } [2] http://cr.openjdk.java.net/~bpb/8231174/webrev.02/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Mon Sep 23 20:11:27 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 23 Sep 2019 21:11:27 +0100 Subject: RFR 8231187: SelectorProvider.inheritedChannel() returns TCP socket channel for Unix domain socket In-Reply-To: <5D890930.9040503@oracle.com> References: <5D84A1A7.4020407@oracle.com> <24d7b2dd-56f3-aac5-abe7-d605507039d7@oracle.com> <5D84B070.9020708@oracle.com> <840c694e-3b49-1c93-f638-ddf009ed1fa4@oracle.com> <5D88F943.4010604@oracle.com> <3f4f20a5-88d7-f939-2b0b-2a1ed3478a76@oracle.com> <5D890930.9040503@oracle.com> Message-ID: <1e8336ea-e0c1-f0e5-2802-7ea44d5a0eaa@oracle.com> On 23/09/2019 19:04, Michael McMahon wrote: > I've just updated the webrev in place with those changes. Thanks, that addresses all my issues. -Alan From Alan.Bateman at oracle.com Mon Sep 23 20:14:36 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 23 Sep 2019 21:14:36 +0100 Subject: 8231174: (fs) FileTime should have 100ns resolution (win) In-Reply-To: <8A4EBD48-4D54-4723-8EBC-2C09443EAB18@oracle.com> References: <04c79988-3949-6b70-d676-b9bf64caab28@oracle.com> <5c4c1c13-c859-c9ac-6dd1-6b2d4dd78fb9@oracle.com> <8A4EBD48-4D54-4723-8EBC-2C09443EAB18@oracle.com> Message-ID: On 23/09/2019 20:13, Brian Burkhalter wrote: > > I think that this version [1,2] should address the concern. > Partly, there is also this adjustment that could overflow: ?? time += WINDOWS_EPOCH_IN_100NS; -Alan. From lance.andersen at oracle.com Mon Sep 23 20:32:32 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Mon, 23 Sep 2019 16:32:32 -0400 Subject: RFR: 8231093: Document the ZIP FS properties noCompression and releaseVersion In-Reply-To: References: <8011ADA5-68A0-47D3-9D11-A53DCDCA0C11@oracle.com> Message-ID: <70566DDF-0779-45FD-B0F2-B73C0D44D199@oracle.com> Thank you for the feedback Alan. More below > On Sep 23, 2019, at 2:32 PM, Alan Bateman wrote: > > On 22/09/2019 23:43, Lance Andersen wrote: >> I updated the patch and the CSR. >> >> The updated webrev is: http://cr.openjdk.java.net/~lancea/8231093/webrev.01/index.html >> > I went through the spec updates in module-info.java. > > "when adding entries ...". Is that also true when someone re-writes a file? Yes it does. I can change ?adding? to ?writing" > > Do we need quotes around "STORED" and "DEFLATED" value to make it clearer that they are strings? Sure I can add the quotes > > "an IllegalArgumentException will be thrown". This could be expanded to say that will be thrown when creating the file system. I can include the additional wording > > For releaseVersion there are 3 list items that start "If the value ..." and one that starts with "If the Object". We should keep the wording consistent. Also it feels like it accepts too many possible value types and maybe some of these should be dropped. Please see below WRT dropping Version > > Could we link "multi-release JAR" to the "Multi-release JAR files" section of the JAR file spec. I think {@docRoot}/../specs/jar/jar.html should work. > Sure I can add that? > When the value of releaseVersion is a String or Integer then it's the feature version. In MR JARs the version is the major version of the Java platform release so "11.0.1" shouldn't be in the example. I can drop 11.0.1 from the example. Runtime.Version.parse() will accept ?11.0.1? and return ?11? which is the only reason I included the example . I can remove the ?11.0.1? from the example. > > The paragraph for a value of "runtime" or Runtime.Version is a bit difficult to read. I think you want "runtime" to use Runtime.version().feature(). If a Runtime.Version object is provided then it's feature() method will be invoked. Maybe it would be better to split these out or maybe allowing a Runtime.Version object should be dropped to reduce the number of possible value types. I am more than happy to drop the Runtime.Version object. However as you are probably aware it was there previously and while it is probably highly unlikely that anyone is passing a Version object, if we drop it from the new?runtimeVersion? property, I assume we drop it from the ?multi-release? property as well? I can update the CSR to indicate we are dropping Version. Best Lance > > -Alan > > 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 Mon Sep 23 21:28:00 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 23 Sep 2019 14:28:00 -0700 Subject: 8231174: (fs) FileTime should have 100ns resolution (win) In-Reply-To: References: <04c79988-3949-6b70-d676-b9bf64caab28@oracle.com> <5c4c1c13-c859-c9ac-6dd1-6b2d4dd78fb9@oracle.com> <8A4EBD48-4D54-4723-8EBC-2C09443EAB18@oracle.com> Message-ID: > On Sep 23, 2019, at 1:14 PM, Alan Bateman wrote: > > On 23/09/2019 20:13, Brian Burkhalter wrote: >> >> I think that this version [1,2] should address the concern. >> > Partly, there is also this adjustment that could overflow: > time += WINDOWS_EPOCH_IN_100NS; I thought of that but didn?t think it could happen or is very improbable. This [1] should account for it as well. Thanks, Brian [1] http://cr.openjdk.java.net/~bpb/8231174/webrev.03/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From lance.andersen at oracle.com Mon Sep 23 23:42:14 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Mon, 23 Sep 2019 19:42:14 -0400 Subject: RFR: 8231093: Document the ZIP FS properties noCompression and releaseVersion In-Reply-To: <70566DDF-0779-45FD-B0F2-B73C0D44D199@oracle.com> References: <8011ADA5-68A0-47D3-9D11-A53DCDCA0C11@oracle.com> <70566DDF-0779-45FD-B0F2-B73C0D44D199@oracle.com> Message-ID: <94543DF4-C19D-47D8-A2A2-B8567D300440@oracle.com> Please see http://cr.openjdk.java.net/~lancea/8231093/webrev.02/index.html As part of the latest update, I removed the documentation on specifying a Version Object for the ?runtimeVersion? property. I did however leave the code in place for backward compatibility. I believe the rest of your input has been addressed. I also updated the CSR. Mach5 tiers1-3 run clean Best Lance > On Sep 23, 2019, at 4:32 PM, Lance Andersen wrote: > > Thank you for the feedback Alan. > > More below > >> On Sep 23, 2019, at 2:32 PM, Alan Bateman > wrote: >> >> On 22/09/2019 23:43, Lance Andersen wrote: >>> I updated the patch and the CSR. >>> >>> The updated webrev is: http://cr.openjdk.java.net/~lancea/8231093/webrev.01/index.html >>> >> I went through the spec updates in module-info.java. >> >> "when adding entries ...". Is that also true when someone re-writes a file? > Yes it does. I can change ?adding? to ?writing" >> >> Do we need quotes around "STORED" and "DEFLATED" value to make it clearer that they are strings? > Sure I can add the quotes >> >> "an IllegalArgumentException will be thrown". This could be expanded to say that will be thrown when creating the file system. > I can include the additional wording >> >> For releaseVersion there are 3 list items that start "If the value ..." and one that starts with "If the Object". We should keep the wording consistent. Also it feels like it accepts too many possible value types and maybe some of these should be dropped. > > Please see below WRT dropping Version >> >> Could we link "multi-release JAR" to the "Multi-release JAR files" section of the JAR file spec. I think {@docRoot}/../specs/jar/jar.html should work. >> > Sure I can add that? > >> When the value of releaseVersion is a String or Integer then it's the feature version. In MR JARs the version is the major version of the Java platform release so "11.0.1" shouldn't be in the example. > I can drop 11.0.1 from the example. Runtime.Version.parse() will accept ?11.0.1? and return ?11? which is the only reason I included the example . I can remove the ?11.0.1? from the example. >> >> The paragraph for a value of "runtime" or Runtime.Version is a bit difficult to read. I think you want "runtime" to use Runtime.version().feature(). If a Runtime.Version object is provided then it's feature() method will be invoked. Maybe it would be better to split these out or maybe allowing a Runtime.Version object should be dropped to reduce the number of possible value types. > > I am more than happy to drop the Runtime.Version object. However as you are probably aware it was there previously and while it is probably highly unlikely that anyone is passing a Version object, if we drop it from the new?runtimeVersion? property, I assume we drop it from the ?multi-release? property as well? I can update the CSR to indicate we are dropping Version. > > Best > Lance >> >> -Alan >> >> > > > > 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 > > > 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 Alan.Bateman at oracle.com Tue Sep 24 06:45:19 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 24 Sep 2019 07:45:19 +0100 Subject: RFR: 8231093: Document the ZIP FS properties noCompression and releaseVersion In-Reply-To: <94543DF4-C19D-47D8-A2A2-B8567D300440@oracle.com> References: <8011ADA5-68A0-47D3-9D11-A53DCDCA0C11@oracle.com> <70566DDF-0779-45FD-B0F2-B73C0D44D199@oracle.com> <94543DF4-C19D-47D8-A2A2-B8567D300440@oracle.com> Message-ID: <54cc0d30-3520-f478-6093-77c189b5113a@oracle.com> On 24/09/2019 00:42, Lance Andersen wrote: > Please see > http://cr.openjdk.java.net/~lancea/8231093/webrev.02/index.html > > As part of the latest update, I removed the documentation on > specifying ?a Version Object for the ?runtimeVersion? property. > > I did however leave the code in place for backward compatibility. ? I > believe the rest of your input has been addressed. > > I also updated the CSR. > The javadoc in this version looks okay to me. -Alan From chris.hegarty at oracle.com Tue Sep 24 09:17:00 2019 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 24 Sep 2019 10:17:00 +0100 Subject: RFR 8231187: SelectorProvider.inheritedChannel() returns TCP socket channel for Unix domain socket In-Reply-To: <5D890930.9040503@oracle.com> References: <5D84A1A7.4020407@oracle.com> <24d7b2dd-56f3-aac5-abe7-d605507039d7@oracle.com> <5D84B070.9020708@oracle.com> <840c694e-3b49-1c93-f638-ddf009ed1fa4@oracle.com> <5D88F943.4010604@oracle.com> <3f4f20a5-88d7-f939-2b0b-2a1ed3478a76@oracle.com> <5D890930.9040503@oracle.com> Message-ID: <89CB2590-E7BB-4CAA-8BB8-A57827F789E6@oracle.com> Michael, > On 23 Sep 2019, at 19:04, Michael McMahon wrote: > > On 23/09/2019, 18:32, Alan Bateman wrote: >> On 23/09/2019 17:56, Michael McMahon wrote: >>> Okay, I see the reason for it now. It is the potential race when closing a socket >>> and its file descriptor possibly being reassigned to another opened file, at the same time >>> as another thread starting an I/O operation on the original socket. >>> >>> I have added the two stage close logic similar to SocketChannel and the Source/SinkChannels you >>> mentioned. >>> >>> Updated webrev at: http://cr.openjdk.java.net/~michaelm/8231187/webrev.2/index.html This looks good. A few comments.. - I only see one usage of private UnixDomainSocketChannelImpl::getFD accessor, while other usages deference the field directly. Can getFD be removed, or why is that usage different? - I'm a little confused by the following, in UnixDomainSocketChannelImpl: 156 } finally { 157 endRead(n > 0); 158 if (n <= 0) 159 return IOStatus.EOF; 160 } 161 return IOStatus.normalize(n); Is it always the case that if `n` is less than or equal to zero, that the socket is at EOF? what about errors? If the former is true, then there is no need to normalize `n`, it is guaranteed to be positive, no? - In UnixDomainSocketChannelImpl(..) 69 UnixDomainSocketChannelImpl(FileDescriptor fd) 70 throws IOException 71 { 72 this.fd = fd; 73 this.state = ST_INUSE; 74 } The setting of the state here is, without holding the stateLock, raises questions. But it should be safe since ST_INUSE is the primitive's default initial value, `0`. If that were to change, then not holding the lock could be problematic. Maybe just grab the lock. - In UnixDomainSocketChannelImpl: 170 * @throws ClosedChannelException if the channel is closed or output shutdown output cannot be shutdown - please remove "or output shutdown" - Maybe update the copyright year ranges in the existing files -Chris. -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.x.mcmahon at oracle.com Tue Sep 24 11:21:14 2019 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Tue, 24 Sep 2019 12:21:14 +0100 Subject: RFR 8231187: SelectorProvider.inheritedChannel() returns TCP socket channel for Unix domain socket In-Reply-To: <89CB2590-E7BB-4CAA-8BB8-A57827F789E6@oracle.com> References: <5D84A1A7.4020407@oracle.com> <24d7b2dd-56f3-aac5-abe7-d605507039d7@oracle.com> <5D84B070.9020708@oracle.com> <840c694e-3b49-1c93-f638-ddf009ed1fa4@oracle.com> <5D88F943.4010604@oracle.com> <3f4f20a5-88d7-f939-2b0b-2a1ed3478a76@oracle.com> <5D890930.9040503@oracle.com> <89CB2590-E7BB-4CAA-8BB8-A57827F789E6@oracle.com> Message-ID: <5D89FC2A.4020404@oracle.com> Hi Chris, On 24/09/2019, 10:17, Chris Hegarty wrote: > Michael, > >> On 23 Sep 2019, at 19:04, Michael McMahon >> > >> wrote: >> >> On 23/09/2019, 18:32, Alan Bateman wrote: >>> On 23/09/2019 17:56, Michael McMahon wrote: >>>> Okay, I see the reason for it now. It is the potential race when >>>> closing a socket >>>> and its file descriptor possibly being reassigned to another opened >>>> file, at the same time >>>> as another thread starting an I/O operation on the original socket. >>>> >>>> I have added the two stage close logic similar to SocketChannel and >>>> the Source/SinkChannels you >>>> mentioned. >>>> >>>> Updated webrev at: >>>> http://cr.openjdk.java.net/~michaelm/8231187/webrev.2/index.html >>>> > > > This looks good. A few comments.. > > - I only see one usage of private UnixDomainSocketChannelImpl::getFD > accessor, while other usages deference the field directly. Can getFD > be removed, or why is that usage different? > Yes, getFD was previously package private so used externally as well. It can be removed completely at this point. > - I'm a little confused by the following, in > UnixDomainSocketChannelImpl: > > 156 } finally { > 157 endRead(n > 0); > 158 if (n <= 0) > 159 return IOStatus.EOF; > 160 } > 161 return IOStatus.normalize(n); > > Is it always the case that if `n` is less than or equal to zero, > that the socket is at EOF? what about errors? If the former is > true, then there is no need to normalize `n`, it is guaranteed to be > positive, no? > Hmm. Yes, I think the two lines 158:159 are redundant and also the normalize call at 161, and the equivalent call in the write method. This code originated obviously in classes that need to support the non-blocking case where the relevant return codes may need to be normalized. - In UnixDomainSocketChannelImpl(..) > > 69 UnixDomainSocketChannelImpl(FileDescriptor fd) > 70 throws IOException > 71 { > 72 this.fd = fd; > 73 this.state = ST_INUSE; > 74 } > > The setting of the state here is, without holding the stateLock, > raises questions. But it should be safe since ST_INUSE is the > primitive's default initial value, `0`. If that were to change, then > not holding the lock could be problematic. Maybe just grab the lock. > Or just do what the related classes do, and not bother to explicitly initialize in the constructor. > - In UnixDomainSocketChannelImpl: > > 170 * @throws ClosedChannelException if the channel is closed > or output shutdown > > output cannot be shutdown - please remove "or output shutdown" > > OK > - Maybe update the copyright year ranges in the existing files Right, yes. Thanks Michael. > > -Chris. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Tue Sep 24 15:25:31 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 24 Sep 2019 16:25:31 +0100 Subject: RFR[8230946]: Clarify security manager behaviour of a connected DatagramSocket and DatagramChannel In-Reply-To: References: Message-ID: On 24/09/2019 16:01, Patrick Concannon wrote: > Hi, > > > Would it be possible to have both my fix JDK-8230946, and CSR > JDK-8231305, reviewed? > > This fix and CSR addresses the javadocs for DatagramSocket::receive, > DatagramChannel::connect and DatagramChannel::receive and aims at > clarifying the Security Manager behaviour on a connected > DatagramSocket/DatagramChannel. > > webrev: http://cr.openjdk.java.net/~pconcannon/8230946/webrevs/webrev.03/ > > CSR: https://bugs.openjdk.java.net/browse/JDK-8231305 The update to DatagramChannel.connect looks okay. In DatagramSocket.receive then I wonder if the "On a send operation, ..." sentence is needed as the send method already specifies IAE. The clarification to DatagramSocket.receive on how it behaves when there is a security manager and not connected may require some adjusting to DatagramChannel's receive spec too. The specification is that a SecurityException is thrown but the implementation behavior is to drop the datagram. Separate issue but we should try to fix that while in the area. I also note that both DatagramSocket and DatagramChannel may have to bind on first usage which may involve a permission check that we should ensure all succeeds. -Alan. From Alan.Bateman at oracle.com Tue Sep 24 18:27:41 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 24 Sep 2019 19:27:41 +0100 Subject: Socket timeout semantics In-Reply-To: References: Message-ID: <9e52dfdb-3272-21f2-2029-38337ea1645b@oracle.com> On 24/09/2019 16:32, Milan Mimica wrote: > : > > I looked into it and found this: > The difference is how Java_sun_nio_ch_Net_poll is implemented. On unix > it uses poll(2), on Windows it uses select(2). Regarding timeouts, > poll() has "wait at least"[2] semantics and overruns by design, while > select() on windows has "waits at most" semantics, or how they put > it: "specifies the maximum time that select should wait before > returning."[3]. It returns early by design! Old, "plain" socket impl > are not much different. > > System.nanoTime is implemented on QueryPerformanceCounter to read the high res time stamp. It's not clear which timer is used by Windows to support select (and WSAPoll) - were you able to get any info on that? -Alan From brian.burkhalter at oracle.com Tue Sep 24 20:19:08 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 24 Sep 2019 13:19:08 -0700 Subject: 8231174: (fs) FileTime should have 100ns resolution (win) In-Reply-To: References: <04c79988-3949-6b70-d676-b9bf64caab28@oracle.com> <5c4c1c13-c859-c9ac-6dd1-6b2d4dd78fb9@oracle.com> <8A4EBD48-4D54-4723-8EBC-2C09443EAB18@oracle.com> Message-ID: <6829A7DC-EADD-46FF-A25D-E74C66759765@oracle.com> > On Sep 23, 2019, at 2:28 PM, Brian Burkhalter wrote: > >> On Sep 23, 2019, at 1:14 PM, Alan Bateman > wrote: >> >> On 23/09/2019 20:13, Brian Burkhalter wrote: >>> >>> I think that this version [1,2] should address the concern. >>> >> Partly, there is also this adjustment that could overflow: >> time += WINDOWS_EPOCH_IN_100NS; > > I thought of that but didn?t think it could happen or is very improbable. This [1] should account for it as well. Here?s one more iteration with (hopefully) simplified versions of toFileTime() and toWindowsTime(). http://cr.openjdk.java.net/~bpb/8231174/webrev.04/ Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Wed Sep 25 06:24:59 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 25 Sep 2019 07:24:59 +0100 Subject: 8231174: (fs) FileTime should have 100ns resolution (win) In-Reply-To: <6829A7DC-EADD-46FF-A25D-E74C66759765@oracle.com> References: <04c79988-3949-6b70-d676-b9bf64caab28@oracle.com> <5c4c1c13-c859-c9ac-6dd1-6b2d4dd78fb9@oracle.com> <8A4EBD48-4D54-4723-8EBC-2C09443EAB18@oracle.com> <6829A7DC-EADD-46FF-A25D-E74C66759765@oracle.com> Message-ID: On 24/09/2019 21:19, Brian Burkhalter wrote: > > Here?s one more iteration with (hopefully) simplified versions of > toFileTime() and toWindowsTime(). > > http://cr.openjdk.java.net/~bpb/8231174/webrev.04/ > This is much simpler - thanks! -Alan From christoph.langer at sap.com Wed Sep 25 10:58:13 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 25 Sep 2019 10:58:13 +0000 Subject: RFR: 8231093: Document the ZIP FS properties noCompression and releaseVersion In-Reply-To: <94543DF4-C19D-47D8-A2A2-B8567D300440@oracle.com> References: <8011ADA5-68A0-47D3-9D11-A53DCDCA0C11@oracle.com> <70566DDF-0779-45FD-B0F2-B73C0D44D199@oracle.com> <94543DF4-C19D-47D8-A2A2-B8567D300440@oracle.com> Message-ID: Hi Lance, first of all, thanks for doing these updates to zipfs. It gets better and better ?? I?ve been looking at the change now, too. Here are my findings: JarFileSystem.java: Line 96: remove Line 98: space should be between if and (, not after (. Line 103: there are quite some spaces (too much) between return and o Generally I?m wondering whether the classes JarFileSystem and JarFileSystemProvider couldn?t be removed at all and we could just add this multi-release implementation part into the ZipFileSystem class. But that could be a subsequent change. ZipFileSystem.java: Line 92: private static final String COMPRESSION_METHOD = "compressionMethod"; I?d prefer if we could start the property definition constants with PROP_, so, could you use PROP_COMPRESSION_METHOD? And probably also the constants in line 84-87 should be aligned to PROP_POSIX, PROP_DEFAULT_OWNER ? (I was using OPT for ?Option? when I created them but probably the word ?property? makes more sense here). Iine 94: public static final String DEFLATED_COMPRESSION_METHOD -> this should probably be private. I?d also rather use COMPRESSION_METHOD_DEFLATED line 96: public static final String STORED_COMPRESSION_METHOD -> same: should be private and COMPRESSION_METHOD_STORED line 173: insert a space between use and (STORED or DEFLATED) line 177: Should be compatibility rather than compatability method getDefaultCompressionMethod (line 181 ff) I?d rather code it like: If (env.containsKey(COMPRESSION_METHOD)) { ? } else { return isTrue(env, "noCompression") ? METHOD_STORED : METHOD_DEFLATED; } Independent of that in lines 184, 186 and 187 you could insert a space after the if. That would match more with the style of the rest of the file. Also line 188, I?d prefer a space between switch and ( Line 202: String.format is missing the argument COMPRESSION_METHOD. ZipFileSystemProvider.java: In line 57 and 60, I?d declare the constants rather package private than protected. Line 59: compatibility Line 126/127: You can just do ?return getZipFileSystem(path, env);? module-info.java: line 241: start with a ?be? -> will be considered? MultiReleaseJarTest.java: Line 132, 133: Add a space after the , CompressionModeTest.java: You could remove the empty lines 153 and 170. Thanks & Best regards Christoph From: nio-dev On Behalf Of Lance Andersen Sent: Dienstag, 24. September 2019 01:42 To: Alan Bateman Cc: nio-dev Subject: Re: RFR: 8231093: Document the ZIP FS properties noCompression and releaseVersion Please see http://cr.openjdk.java.net/~lancea/8231093/webrev.02/index.html As part of the latest update, I removed the documentation on specifying a Version Object for the ?runtimeVersion? property. I did however leave the code in place for backward compatibility. I believe the rest of your input has been addressed. I also updated the CSR. Mach5 tiers1-3 run clean Best Lance On Sep 23, 2019, at 4:32 PM, Lance Andersen > wrote: Thank you for the feedback Alan. More below On Sep 23, 2019, at 2:32 PM, Alan Bateman > wrote: On 22/09/2019 23:43, Lance Andersen wrote: I updated the patch and the CSR. The updated webrev is: http://cr.openjdk.java.net/~lancea/8231093/webrev.01/index.html I went through the spec updates in module-info.java. "when adding entries ...". Is that also true when someone re-writes a file? Yes it does. I can change ?adding? to ?writing" Do we need quotes around "STORED" and "DEFLATED" value to make it clearer that they are strings? Sure I can add the quotes "an IllegalArgumentException will be thrown". This could be expanded to say that will be thrown when creating the file system. I can include the additional wording For releaseVersion there are 3 list items that start "If the value ..." and one that starts with "If the Object". We should keep the wording consistent. Also it feels like it accepts too many possible value types and maybe some of these should be dropped. Please see below WRT dropping Version Could we link "multi-release JAR" to the "Multi-release JAR files" section of the JAR file spec. I think {@docRoot}/../specs/jar/jar.html should work. Sure I can add that? When the value of releaseVersion is a String or Integer then it's the feature version. In MR JARs the version is the major version of the Java platform release so "11.0.1" shouldn't be in the example. I can drop 11.0.1 from the example. Runtime.Version.parse() will accept ?11.0.1? and return ?11? which is the only reason I included the example . I can remove the ?11.0.1? from the example. The paragraph for a value of "runtime" or Runtime.Version is a bit difficult to read. I think you want "runtime" to use Runtime.version().feature(). If a Runtime.Version object is provided then it's feature() method will be invoked. Maybe it would be better to split these out or maybe allowing a Runtime.Version object should be dropped to reduce the number of possible value types. I am more than happy to drop the Runtime.Version object. However as you are probably aware it was there previously and while it is probably highly unlikely that anyone is passing a Version object, if we drop it from the new?runtimeVersion? property, I assume we drop it from the ?multi-release? property as well? I can update the CSR to indicate we are dropping Version. Best Lance -Alan 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 [cid:image001.gif at 01D57396.C1EFE230] 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: image001.gif Type: image/gif Size: 658 bytes Desc: image001.gif URL: From lance.andersen at oracle.com Wed Sep 25 18:23:57 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Wed, 25 Sep 2019 14:23:57 -0400 Subject: RFR: 8231093: Document the ZIP FS properties noCompression and releaseVersion In-Reply-To: References: <8011ADA5-68A0-47D3-9D11-A53DCDCA0C11@oracle.com> <70566DDF-0779-45FD-B0F2-B73C0D44D199@oracle.com> <94543DF4-C19D-47D8-A2A2-B8567D300440@oracle.com> Message-ID: <2EACDE3F-013A-4AAA-A909-0E8A811FBED5@oracle.com> Hi Christoph Thank you for the feedback, more below: > On Sep 25, 2019, at 6:58 AM, Langer, Christoph wrote: > > Hi Lance, > > first of all, thanks for doing these updates to zipfs. It gets better and better ?? :-) > > I?ve been looking at the change now, too. Here are my findings: > > JarFileSystem.java: > Line 96: remove done > Line 98: space should be between if and (, not after (. done > Line 103: there are quite some spaces (too much) between return and o done > > Generally I?m wondering whether the classes JarFileSystem and JarFileSystemProvider couldn?t be removed at all and we could just add this multi-release implementation part into the ZipFileSystem class. Well that is beyond the scope of this change :-) > But that could be a subsequent change. I was not involved, but it might have been discussed as part of http://hg.openjdk.java.net/jdk9/dev/jdk/rev/5cebf921be7a But yes, any changes should be handled separately > > ZipFileSystem.java: > Line 92: private static final String COMPRESSION_METHOD = "compressionMethod"; > I?d prefer if we could start the property definition constants with PROP_, so, could you use PROP_COMPRESSION_METHOD? And probably also the constants in line 84-87 should be aligned to PROP_POSIX, PROP_DEFAULT_OWNER ? (I was using OPT for ?Option? when I created them but probably the word ?property? makes more sense here). Ok, I changed them to PROPERTY_ vs PROP_ including the POSIX properties > > Iine 94: public static final String DEFLATED_COMPRESSION_METHOD -> this should probably be private. I?d also rather use COMPRESSION_METHOD_DEFLATED > line 96: public static final String STORED_COMPRESSION_METHOD -> same: should be private and COMPRESSION_METHOD_STORED Changed the names and I intended to make them private originally but missed that when I refactored via intellij > line 173: insert a space between use and (STORED or DEFLATED) done > line 177: Should be compatibility rather than compatability done > method getDefaultCompressionMethod (line 181 ff) > > I?d rather code it like: > If (env.containsKey(COMPRESSION_METHOD)) { > ? > } else { > return isTrue(env, "noCompression") ? METHOD_STORED : METHOD_DEFLATED; > } > I left it as it was as I think this comes to style choice > Independent of that in lines 184, 186 and 187 you could insert a space after the if. That would match more with the style of the rest of the file. Also line 188, I?d prefer a space between switch and ( done > > Line 202: String.format is missing the argument COMPRESSION_METHOD. done > > ZipFileSystemProvider.java: > In line 57 and 60, I?d declare the constants rather package private than protected. > Line 59: compatibility done > Line 126/127: You can just do ?return getZipFileSystem(path, env);? done > > module-info.java: > line 241: start with a ?be? -> will be considered? done > > MultiReleaseJarTest.java: > Line 132, 133: Add a space after the , done > > CompressionModeTest.java: > You could remove the empty lines 153 and 170. done The revised webrev can be found at http://cr.openjdk.java.net/~lancea/8231093/webrev.03/index.html Mach5 jdk tiers 1-3 are still clean Thank you again. Best Lance > > Thanks & Best regards > Christoph > > > From: nio-dev > On Behalf Of Lance Andersen > Sent: Dienstag, 24. September 2019 01:42 > To: Alan Bateman > > Cc: nio-dev > > Subject: Re: RFR: 8231093: Document the ZIP FS properties noCompression and releaseVersion > > Please see http://cr.openjdk.java.net/~lancea/8231093/webrev.02/index.html > > As part of the latest update, I removed the documentation on specifying a Version Object for the ?runtimeVersion? property. > > I did however leave the code in place for backward compatibility. I believe the rest of your input has been addressed. > > I also updated the CSR. > > Mach5 tiers1-3 run clean > > Best > Lance > On Sep 23, 2019, at 4:32 PM, Lance Andersen > wrote: > > Thank you for the feedback Alan. > > More below > > On Sep 23, 2019, at 2:32 PM, Alan Bateman > wrote: > > On 22/09/2019 23:43, Lance Andersen wrote: > > I updated the patch and the CSR. > > The updated webrev is: http://cr.openjdk.java.net/~lancea/8231093/webrev.01/index.html > I went through the spec updates in module-info.java. > > "when adding entries ...". Is that also true when someone re-writes a file? > Yes it does. I can change ?adding? to ?writing" > > > Do we need quotes around "STORED" and "DEFLATED" value to make it clearer that they are strings? > Sure I can add the quotes > > > "an IllegalArgumentException will be thrown". This could be expanded to say that will be thrown when creating the file system. > I can include the additional wording > > > For releaseVersion there are 3 list items that start "If the value ..." and one that starts with "If the Object". We should keep the wording consistent. Also it feels like it accepts too many possible value types and maybe some of these should be dropped. > > Please see below WRT dropping Version > > > Could we link "multi-release JAR" to the "Multi-release JAR files" section of the JAR file spec. I think{@docRoot}/../specs/jar/jar.html should work. > > Sure I can add that? > > > When the value of releaseVersion is a String or Integer then it's the feature version. In MR JARs the version is the major version of the Java platform release so "11.0.1" shouldn't be in the example. > I can drop 11.0.1 from the example. Runtime.Version.parse() will accept ?11.0.1? and return ?11? which is the only reason I included the example . I can remove the ?11.0.1? from the example. > > > The paragraph for a value of "runtime" or Runtime.Version is a bit difficult to read. I think you want "runtime" to use Runtime.version().feature(). If a Runtime.Version object is provided then it's feature() method will be invoked. Maybe it would be better to split these out or maybe allowing a Runtime.Version object should be dropped to reduce the number of possible value types. > > I am more than happy to drop the Runtime.Version object. However as you are probably aware it was there previously and while it is probably highly unlikely that anyone is passing a Version object, if we drop it from the new?runtimeVersion? property, I assume we drop it from the ?multi-release? property as well? I can update the CSR to indicate we are dropping Version. > > Best > Lance > > > -Alan > > > > > > 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 > > > > > > > > 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 > > > > 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 christoph.langer at sap.com Fri Sep 27 10:21:08 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 27 Sep 2019 10:21:08 +0000 Subject: RFR: 8231093: Document the ZIP FS properties noCompression and releaseVersion In-Reply-To: <2EACDE3F-013A-4AAA-A909-0E8A811FBED5@oracle.com> References: <8011ADA5-68A0-47D3-9D11-A53DCDCA0C11@oracle.com> <70566DDF-0779-45FD-B0F2-B73C0D44D199@oracle.com> <94543DF4-C19D-47D8-A2A2-B8567D300440@oracle.com> <2EACDE3F-013A-4AAA-A909-0E8A811FBED5@oracle.com> Message-ID: Hi Lance, thanks for updating the webrev. It looks good now. Regarding refactoring the JarFileSystem/JarFileSystemProvider classes, I plan to have a look at after this change got pushed. Best regards Christoph > -----Original Message----- > From: Lance Andersen > Sent: Mittwoch, 25. September 2019 20:24 > To: Langer, Christoph > Cc: nio-dev > Subject: Re: RFR: 8231093: Document the ZIP FS properties noCompression > and releaseVersion > > Hi Christoph > > Thank you for the feedback, more below: > > On Sep 25, 2019, at 6:58 AM, Langer, Christoph > wrote: > > Hi Lance, > > first of all, thanks for doing these updates to zipfs. It gets better and > better??? > :-) > > > I?ve been looking at the change now, too. Here are my findings: > > JarFileSystem.java: > Line 96: remove > done > > Line 98: space should be between if and (, not after (. > done > > Line 103: there are quite some spaces (too much) between return and o > > done > > Generally I?m wondering whether the classes JarFileSystem and > JarFileSystemProvider couldn?t be removed at all and we could just add this > multi-release implementation part into the ZipFileSystem class. > > Well that is beyond the scope of this change :-) > > But that could be a subsequent change. > > I was not involved, but it might have been discussed as part > of?http://hg.openjdk.java.net/jdk9/dev/jdk/rev/5cebf921be7a > > > But yes, any changes should be handled separately > > > ZipFileSystem.java: > Line 92: private static final String COMPRESSION_METHOD = > "compressionMethod"; > I?d prefer if we could start the property definition constants with PROP_, so, > could you use PROP_COMPRESSION_METHOD? And probably also the > constants in line 84-87 should be aligned to PROP_POSIX, > PROP_DEFAULT_OWNER ? (I was using OPT for ?Option? when I created > them but probably the word ?property? makes more sense here). > Ok, ?I changed them to PROPERTY_ vs PROP_ ?including the POSIX properties > > Iine 94: public static final String DEFLATED_COMPRESSION_METHOD -> this > should probably be private. I?d also rather use > COMPRESSION_METHOD_DEFLATED > line 96:?public static final String STORED_COMPRESSION_METHOD -> same: > should be private and COMPRESSION_METHOD_STORED > Changed the names and I intended to make them private originally but > missed that when I refactored via intellij > > line 173: insert a space between use and (STORED or DEFLATED) > done > > line 177: Should be compatibility rather than compatability > done > > method getDefaultCompressionMethod (line 181 ff) > > I?d rather code it like: > If (env.containsKey(COMPRESSION_METHOD)) { > ??? ? > } else { > ??? return isTrue(env, "noCompression") ? METHOD_STORED : > METHOD_DEFLATED; > } > > I left it as it was as I think this comes to style choice > > > Independent of that in lines 184, 186 and 187 you could insert a space after > the if. That would match more with the style of the rest of the file. Also line > 188, I?d prefer a space between switch and ( > done > > > Line 202: String.format is missing the argument COMPRESSION_METHOD. > done > > > ZipFileSystemProvider.java: > In line 57 and 60, I?d declare the constants rather package private than > protected. > Line 59: compatibility > done > > Line 126/127: You can just do ?return getZipFileSystem(path, env);? > done > > > module-info.java: > line 241: start with a ?be? -> will be considered? > done > > > MultiReleaseJarTest.java: > Line 132, 133: Add a space after the , > done > > > CompressionModeTest.java: > You could remove the empty lines 153 and 170. > done > > The revised webrev can be found > at ?http://cr.openjdk.java.net/~lancea/8231093/webrev.03/index.html > > Mach5 jdk tiers 1-3 are still clean > > Thank you again. > > Best > Lance > > > Thanks & Best regards > Christoph > > > From:?nio-dev ?On Behalf > Of?Lance Andersen > Sent:?Dienstag, 24. September 2019 01:42 > To:?Alan Bateman > Cc:?nio-dev > Subject:?Re: RFR: 8231093: Document the ZIP FS properties noCompression > and releaseVersion > > Please > see ?http://cr.openjdk.java.net/~lancea/8231093/webrev.02/index.html > > As part of the latest update, I removed the documentation on specifying ?a > Version Object for the ?runtimeVersion? property. > > I did however leave the code in place for backward compatibility. ? I believe > the rest of your input has been addressed. > > I also updated the CSR. > > Mach5 tiers1-3 run clean > > Best > Lance > On Sep 23, 2019, at 4:32 PM, Lance Andersen > wrote: > > Thank you for the feedback Alan. > > More below > > On Sep 23, 2019, at 2:32 PM, Alan Bateman > wrote: > > On 22/09/2019 23:43, Lance Andersen wrote: > > > I updated the patch and the CSR. > > The updated webrev > is:?http://cr.openjdk.java.net/~lancea/8231093/webrev.01/index.html > I went through the spec updates in module-info.java. > > "when adding entries ...". Is that also true when someone re-writes a file? > Yes it does. ?I can change ?adding? to ?writing" > > > > Do we need quotes around "STORED" and "DEFLATED"? value to make it > clearer that they are strings? > Sure I can add the quotes > > > > "an IllegalArgumentException will be thrown". This could be expanded to say > that will be thrown when creating the file system. > I can include the additional wording > > > > For releaseVersion there are 3 list items that start "If the value ..." and one > that starts with "If the Object". We should keep the wording consistent. Also > it feels like it accepts too many possible value types and maybe some of > these should be dropped. > > Please see below WRT dropping Version > > > > Could we link "multi-release JAR" to the "Multi-release JAR files" section of > the JAR file spec. I > thinkmailto:%7b at docRoot%7d/../specs/jar/jar.html?should work. > Sure I can add that? > > > > When the value of releaseVersion is a String or Integer then it's the feature > version.? In MR JARs the version is the major version of the Java platform > release so "11.0.1" shouldn't be in the example. > I can drop ?11.0.1 from the example. ?Runtime.Version.parse() will accept > ?11.0.1? and return ?11? which is the only reason I included the example . ?I > can remove the ?11.0.1? from the example. > > > > The paragraph for a value of "runtime" or Runtime.Version is a bit difficult to > read. I think you want "runtime" to use Runtime.version().feature(). If a > Runtime.Version object is provided then it's feature() method will be > invoked. Maybe it would be better to split these out or maybe allowing a > Runtime.Version object should be dropped to reduce the number of > possible value types. > > I am more than happy to drop the Runtime.Version object. ?However as you > are probably aware it was there previously and while it is probably highly > unlikely that anyone is passing a Version object, if we drop it from the > new?runtimeVersion? property, I assume we drop it from the ?multi- > release? property as well? ?I can update the CSR to indicate we are dropping > Version. > > Best > Lance > > > > -Alan > > > > http://oracle.com/us/design/oracle-email-sig-198324.gif > http://oracle.com/us/design/oracle-email-sig-198324.gifLance Andersen| > Principal Member of Technical Staff | +1.781.442.2037 > Oracle?Java Engineering > 1 Network Drive > Burlington, MA 01803 > mailto:Lance.Andersen at oracle.com > > > > > > > http://oracle.com/us/design/oracle-email-sig-198324.gif > http://oracle.com/us/design/oracle-email-sig-198324.gifLance Andersen| > Principal Member of Technical Staff | +1.781.442.2037 > Oracle?Java Engineering > 1 Network Drive > Burlington, MA 01803 > mailto:Lance.Andersen at oracle.com > > > > > > > http://oracle.com/us/design/oracle-email-sig-198324.gif > http://oracle.com/us/design/oracle-email-sig-198324.gifLance Andersen| > Principal Member of Technical Staff | +1.781.442.2037 > Oracle?Java Engineering > 1 Network Drive > Burlington, MA 01803 > mailto:Lance.Andersen at oracle.com > > > From lance.andersen at oracle.com Fri Sep 27 11:29:56 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Fri, 27 Sep 2019 07:29:56 -0400 Subject: RFR: 8231093: Document the ZIP FS properties noCompression and releaseVersion In-Reply-To: References: <8011ADA5-68A0-47D3-9D11-A53DCDCA0C11@oracle.com> <70566DDF-0779-45FD-B0F2-B73C0D44D199@oracle.com> <94543DF4-C19D-47D8-A2A2-B8567D300440@oracle.com> <2EACDE3F-013A-4AAA-A909-0E8A811FBED5@oracle.com> Message-ID: Hi Christoph, > On Sep 27, 2019, at 6:21 AM, Langer, Christoph wrote: > > Hi Lance, > > thanks for updating the webrev. It looks good now. Thank you. Once the CSR is blessed, I will push. > > Regarding refactoring the JarFileSystem/JarFileSystemProvider classes, I plan to have a look at after this change got pushed. OK, I am hoping Alan or Sherman(if he is reading this alias :-) ) might have some of the history. Thank you again! Best Lance > > Best regards > Christoph > >> -----Original Message----- >> From: Lance Andersen >> Sent: Mittwoch, 25. September 2019 20:24 >> To: Langer, Christoph >> Cc: nio-dev >> Subject: Re: RFR: 8231093: Document the ZIP FS properties noCompression >> and releaseVersion >> >> Hi Christoph >> >> Thank you for the feedback, more below: >> >> On Sep 25, 2019, at 6:58 AM, Langer, Christoph >> wrote: >> >> Hi Lance, >> >> first of all, thanks for doing these updates to zipfs. It gets better and >> better ?? >> :-) >> >> >> I?ve been looking at the change now, too. Here are my findings: >> >> JarFileSystem.java: >> Line 96: remove >> done >> >> Line 98: space should be between if and (, not after (. >> done >> >> Line 103: there are quite some spaces (too much) between return and o >> >> done >> >> Generally I?m wondering whether the classes JarFileSystem and >> JarFileSystemProvider couldn?t be removed at all and we could just add this >> multi-release implementation part into the ZipFileSystem class. >> >> Well that is beyond the scope of this change :-) >> >> But that could be a subsequent change. >> >> I was not involved, but it might have been discussed as part >> of http://hg.openjdk.java.net/jdk9/dev/jdk/rev/5cebf921be7a >> >> >> But yes, any changes should be handled separately >> >> >> ZipFileSystem.java: >> Line 92: private static final String COMPRESSION_METHOD = >> "compressionMethod"; >> I?d prefer if we could start the property definition constants with PROP_, so, >> could you use PROP_COMPRESSION_METHOD? And probably also the >> constants in line 84-87 should be aligned to PROP_POSIX, >> PROP_DEFAULT_OWNER ? (I was using OPT for ?Option? when I created >> them but probably the word ?property? makes more sense here). >> Ok, I changed them to PROPERTY_ vs PROP_ including the POSIX properties >> >> Iine 94: public static final String DEFLATED_COMPRESSION_METHOD -> this >> should probably be private. I?d also rather use >> COMPRESSION_METHOD_DEFLATED >> line 96: public static final String STORED_COMPRESSION_METHOD -> same: >> should be private and COMPRESSION_METHOD_STORED >> Changed the names and I intended to make them private originally but >> missed that when I refactored via intellij >> >> line 173: insert a space between use and (STORED or DEFLATED) >> done >> >> line 177: Should be compatibility rather than compatability >> done >> >> method getDefaultCompressionMethod (line 181 ff) >> >> I?d rather code it like: >> If (env.containsKey(COMPRESSION_METHOD)) { >> ? >> } else { >> return isTrue(env, "noCompression") ? METHOD_STORED : >> METHOD_DEFLATED; >> } >> >> I left it as it was as I think this comes to style choice >> >> >> Independent of that in lines 184, 186 and 187 you could insert a space after >> the if. That would match more with the style of the rest of the file. Also line >> 188, I?d prefer a space between switch and ( >> done >> >> >> Line 202: String.format is missing the argument COMPRESSION_METHOD. >> done >> >> >> ZipFileSystemProvider.java: >> In line 57 and 60, I?d declare the constants rather package private than >> protected. >> Line 59: compatibility >> done >> >> Line 126/127: You can just do ?return getZipFileSystem(path, env);? >> done >> >> >> module-info.java: >> line 241: start with a ?be? -> will be considered? >> done >> >> >> MultiReleaseJarTest.java: >> Line 132, 133: Add a space after the , >> done >> >> >> CompressionModeTest.java: >> You could remove the empty lines 153 and 170. >> done >> >> The revised webrev can be found >> at http://cr.openjdk.java.net/~lancea/8231093/webrev.03/index.html >> >> Mach5 jdk tiers 1-3 are still clean >> >> Thank you again. >> >> Best >> Lance >> >> >> Thanks & Best regards >> Christoph >> >> >> From: nio-dev On Behalf >> Of Lance Andersen >> Sent: Dienstag, 24. September 2019 01:42 >> To: Alan Bateman >> Cc: nio-dev >> Subject: Re: RFR: 8231093: Document the ZIP FS properties noCompression >> and releaseVersion >> >> Please >> see http://cr.openjdk.java.net/~lancea/8231093/webrev.02/index.html >> >> As part of the latest update, I removed the documentation on specifying a >> Version Object for the ?runtimeVersion? property. >> >> I did however leave the code in place for backward compatibility. I believe >> the rest of your input has been addressed. >> >> I also updated the CSR. >> >> Mach5 tiers1-3 run clean >> >> Best >> Lance >> On Sep 23, 2019, at 4:32 PM, Lance Andersen >> wrote: >> >> Thank you for the feedback Alan. >> >> More below >> >> On Sep 23, 2019, at 2:32 PM, Alan Bateman >> wrote: >> >> On 22/09/2019 23:43, Lance Andersen wrote: >> >> >> I updated the patch and the CSR. >> >> The updated webrev >> is: http://cr.openjdk.java.net/~lancea/8231093/webrev.01/index.html >> I went through the spec updates in module-info.java. >> >> "when adding entries ...". Is that also true when someone re-writes a file? >> Yes it does. I can change ?adding? to ?writing" >> >> >> >> Do we need quotes around "STORED" and "DEFLATED" value to make it >> clearer that they are strings? >> Sure I can add the quotes >> >> >> >> "an IllegalArgumentException will be thrown". This could be expanded to say >> that will be thrown when creating the file system. >> I can include the additional wording >> >> >> >> For releaseVersion there are 3 list items that start "If the value ..." and one >> that starts with "If the Object". We should keep the wording consistent. Also >> it feels like it accepts too many possible value types and maybe some of >> these should be dropped. >> >> Please see below WRT dropping Version >> >> >> >> Could we link "multi-release JAR" to the "Multi-release JAR files" section of >> the JAR file spec. I >> thinkmailto:%7b at docRoot%7d/../specs/jar/jar.html should work. >> Sure I can add that? >> >> >> >> When the value of releaseVersion is a String or Integer then it's the feature >> version. In MR JARs the version is the major version of the Java platform >> release so "11.0.1" shouldn't be in the example. >> I can drop 11.0.1 from the example. Runtime.Version.parse() will accept >> ?11.0.1? and return ?11? which is the only reason I included the example . I >> can remove the ?11.0.1? from the example. >> >> >> >> The paragraph for a value of "runtime" or Runtime.Version is a bit difficult to >> read. I think you want "runtime" to use Runtime.version().feature(). If a >> Runtime.Version object is provided then it's feature() method will be >> invoked. Maybe it would be better to split these out or maybe allowing a >> Runtime.Version object should be dropped to reduce the number of >> possible value types. >> >> I am more than happy to drop the Runtime.Version object. However as you >> are probably aware it was there previously and while it is probably highly >> unlikely that anyone is passing a Version object, if we drop it from the >> new?runtimeVersion? property, I assume we drop it from the ?multi- >> release? property as well? I can update the CSR to indicate we are dropping >> Version. >> >> Best >> Lance >> >> >> >> -Alan >> >> >> >> http://oracle.com/us/design/oracle-email-sig-198324.gif >> http://oracle.com/us/design/oracle-email-sig-198324.gifLance Andersen| >> Principal Member of Technical Staff | +1.781.442.2037 >> Oracle Java Engineering >> 1 Network Drive >> Burlington, MA 01803 >> mailto:Lance.Andersen at oracle.com >> >> >> >> >> >> >> http://oracle.com/us/design/oracle-email-sig-198324.gif >> http://oracle.com/us/design/oracle-email-sig-198324.gifLance Andersen| >> Principal Member of Technical Staff | +1.781.442.2037 >> Oracle Java Engineering >> 1 Network Drive >> Burlington, MA 01803 >> mailto:Lance.Andersen at oracle.com >> >> >> >> >> >> >> http://oracle.com/us/design/oracle-email-sig-198324.gif >> http://oracle.com/us/design/oracle-email-sig-198324.gifLance Andersen| >> Principal Member of Technical Staff | +1.781.442.2037 >> Oracle Java Engineering >> 1 Network Drive >> Burlington, MA 01803 >> mailto:Lance.Andersen at oracle.com >> >> >> > 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 patrick.concannon at oracle.com Fri Sep 27 15:07:46 2019 From: patrick.concannon at oracle.com (Patrick Concannon) Date: Fri, 27 Sep 2019 16:07:46 +0100 Subject: RFR[8230946]: Clarify security manager behaviour of a connected DatagramSocket and DatagramChannel In-Reply-To: References: Message-ID: Hi Alan, Thanks for the review. On 24/09/2019 16:25, Alan Bateman wrote: > > The clarification to DatagramSocket.receive on how it behaves when > there is a security manager and not connected may require some > adjusting to DatagramChannel's receive spec too. The specification is > that a SecurityException is thrown but the implementation behavior is > to drop the datagram. Separate issue but we should try to fix that > while in the area. I also note that both DatagramSocket and > DatagramChannel may have to bind on first usage which may involve a > permission check that we should ensure all succeeds. > Regarding the above, I can open this as a separate issue if you like? Kind regards, Patrick From Alan.Bateman at oracle.com Fri Sep 27 15:49:37 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 27 Sep 2019 16:49:37 +0100 Subject: RFR[8230946]: Clarify security manager behaviour of a connected DatagramSocket and DatagramChannel In-Reply-To: References: Message-ID: <806a8cef-225e-ba5e-e2d5-74c6610321d0@oracle.com> On 27/09/2019 16:07, Patrick Concannon wrote: > Hi Alan, > > > Thanks for the review. > > On 24/09/2019 16:25, Alan Bateman wrote: >> >> The clarification to DatagramSocket.receive on how it behaves when >> there is a security manager and not connected may require some >> adjusting to DatagramChannel's receive spec too. The specification is >> that a SecurityException is thrown but the implementation behavior is >> to drop the datagram. Separate issue but we should try to fix that >> while in the area. I also note that both DatagramSocket and >> DatagramChannel may have to bind on first usage which may involve a >> permission check that we should ensure all succeeds. >> > > Regarding the above, I can open this as a separate issue if you like? Yes please. -Alan From brian.burkhalter at oracle.com Fri Sep 27 21:02:41 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 27 Sep 2019 14:02:41 -0700 Subject: [RFC] JDK-8162520: (fs) FileStore should support file stores with > Long.MAX_VALUE capacity Message-ID: Hello, There appear to be several ways to approach this problem and I would like to solicit comments and suggestions. In all cases, as suggested in a comment on the issue [1], the extant FileStore.get*Space() methods should probably return a specific value to indicate overflow, e.g., Long.MAX_VALUE, Long.MIN_VALUE, or simply any negative value. Here are some possibilities for APIs: 1. Return the number of blocks of each type long getTotalBlocks(); long getUnallocatedBlocks(); long getUsableBlocks(); The respective sizes in whichever units can then be computed by the caller using the value returned by getBlockSize(). 2. Return size in specified units An enum or something: SizeUnit {BYTES, KILOBYTES, MEGABYTES, GIGABYTES, TERABYTES} // return value: long[] ret = new long[2] // unitSize = number of bytes per unit // ret[0] = count of the number of units: bytes / unitSize // ret[1] = remainder: size % unitSize // exception: size / unitSize > Long.MAX_VALUE long[] getTotalSpace(SizeUnit); long[] getUnallocatedSpace(SizeUnit); long[] getUsableSpace(SizeUnit); 3. Return the size in bytes as a split 128-bit integer // return value: long[] ret = new long[2] // ret[0] = Math.multiplyHigh(f_bsize, n_blocks) // ret[1] = f_bsize * n_blocks // n_blocks in {f_blocks, f_bfree, f_bavail} long[] getTotalBytes(); long[] getFreeBytes(); long[] getAvailableBytes(); 4. Return the size as bytes via a BigInteger // returns f_bsize * f_blocks BigInteger getTotalBytes(); // returns f_bsize * f_bfree BigInteger getFreeBytes(); // returns f_bsize * f_bavail BigInteger getAvailableBytes(); Also, I did not find any native APIs for obtaining sizes which specifically addressed large capacity volumes. Thanks, Brian [1] https://bugs.openjdk.java.net/browse/JDK-8162520 -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Sat Sep 28 00:25:29 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 27 Sep 2019 17:25:29 -0700 Subject: [Ping] 8225461: (fs) Investigate filtering duplicates out of Iterable returned by java.nio.file.FileSystem::getFileStores References: <9F2B2DA6-6351-4465-851A-05D14AA8382A@oracle.com> Message-ID: <6F61D193-6EE2-49EC-924C-56F420CAC7D2@oracle.com> > Begin forwarded message: > > From: Brian Burkhalter > Subject: Re: 8225461: (fs) Investigate filtering duplicates out of Iterable returned by java.nio.file.FileSystem::getFileStores > Date: August 30, 2019 at 4:59:00 PM PDT > To: Alan Bateman > Cc: nio-dev > > >> On Aug 28, 2019, at 2:26 AM, Alan Bateman > wrote: >> >> On 23/08/2019 19:33, Brian Burkhalter wrote: >>> Ping ? ! >> As a short term workaround in the test then this is probably okay although "replicates" looks a bit odd. I would much prefer if we find time to get to root of these issues so that the implementation can handle these cases where there are duplicate or overlay mounts. I realize this will require work to setup these scenarios but we have to get to the underlying issue to avoid the continuous trickle of bug reports with unusual configurations. > > This particular patch was really intended to avoid spurious failures due to misconfigured systems in the CI testing environment. As such it might instead be better addressed under the issue [1]. The issue [2] of the current discussion thread could then be left open to address handling these weird cases in the implementation itself. > > Thanks, > > Brian > > [1] https://bugs.openjdk.java.net/browse/JDK-8225471 > [2] https://bugs.openjdk.java.net/browse/JDK-8225461 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Sat Sep 28 16:07:07 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 28 Sep 2019 17:07:07 +0100 Subject: [RFC] JDK-8162520: (fs) FileStore should support file stores with > Long.MAX_VALUE capacity In-Reply-To: References: Message-ID: <49606851-5b61-6913-0e22-654e4368ad93@oracle.com> On 27/09/2019 22:02, Brian Burkhalter wrote: > : > > 1. Return the number of blocks of each type > > long getTotalBlocks(); > long getUnallocatedBlocks(); > long getUsableBlocks(); > > The respective sizes in whichever units can then be computed by the > caller using the value returned ?by getBlockSize(). This option does fit with the recently added getBlockSize, I just wonder if 2^63 blocks is enough. The native APIs seem to allow up to 2^64 (unsigned). -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From patrick.concannon at oracle.com Mon Sep 30 14:10:05 2019 From: patrick.concannon at oracle.com (Patrick Concannon) Date: Mon, 30 Sep 2019 15:10:05 +0100 Subject: RFR[8230946]: Clarify security manager behaviour of a connected DatagramSocket and DatagramChannel In-Reply-To: <806a8cef-225e-ba5e-e2d5-74c6610321d0@oracle.com> References: <806a8cef-225e-ba5e-e2d5-74c6610321d0@oracle.com> Message-ID: Hi Alan, A new issue has been created as requested, and can be found here: https://bugs.openjdk.java.net/browse/JDK-8231570 Kind regards, Patrick On 27/09/2019 16:49, Alan Bateman wrote: > > > On 27/09/2019 16:07, Patrick Concannon wrote: >> Hi Alan, >> >> >> Thanks for the review. >> >> On 24/09/2019 16:25, Alan Bateman wrote: >>> >>> The clarification to DatagramSocket.receive on how it behaves when >>> there is a security manager and not connected may require some >>> adjusting to DatagramChannel's receive spec too. The specification >>> is that a SecurityException is thrown but the implementation >>> behavior is to drop the datagram. Separate issue but we should try >>> to fix that while in the area. I also note that both DatagramSocket >>> and DatagramChannel may have to bind on first usage which may >>> involve a permission check that we should ensure all succeeds. >>> >> >> Regarding the above, I can open this as a separate issue if you like? > Yes please. > > -Alan From Alan.Bateman at oracle.com Mon Sep 30 14:27:22 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 30 Sep 2019 15:27:22 +0100 Subject: RFR[8230946]: Clarify security manager behaviour of a connected DatagramSocket and DatagramChannel In-Reply-To: References: <806a8cef-225e-ba5e-e2d5-74c6610321d0@oracle.com> Message-ID: <8dc97f45-be76-eb51-6073-b835479790f7@oracle.com> On 30/09/2019 15:10, Patrick Concannon wrote: > Hi Alan, > > > A new issue has been created as requested, and can be found here: > https://bugs.openjdk.java.net/browse/JDK-8231570 In JDK-8231570, I think Chris is concerned that a custom SM will observe, and may prevent, send/receive from binding where as an implicit bind by connect is not observed by the SM. It will not be wrong for the binding in connect to go through the SM too. The related issue that we touched on here is that DatagramChannel.receive does not specify that it discards datagrams when denied by the SM. I think we will need to adjust the wording for the SecurityException. -Alan From chris.hegarty at oracle.com Mon Sep 30 15:45:29 2019 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 30 Sep 2019 16:45:29 +0100 Subject: RFR[8230946]: Clarify security manager behaviour of a connected DatagramSocket and DatagramChannel In-Reply-To: <8dc97f45-be76-eb51-6073-b835479790f7@oracle.com> References: <806a8cef-225e-ba5e-e2d5-74c6610321d0@oracle.com> <8dc97f45-be76-eb51-6073-b835479790f7@oracle.com> Message-ID: On 30/09/2019 15:27, Alan Bateman wrote: > On 30/09/2019 15:10, Patrick Concannon wrote: >> Hi Alan, >> >> >> A new issue has been created as requested, and can be found here: >> https://bugs.openjdk.java.net/browse/JDK-8231570 > In JDK-8231570, I think Chris is concerned that a custom SM will > observe, and may prevent, send/receive from binding where as an implicit > bind by connect is not observed by the SM. It will not be wrong for the > binding in connect to go through the SM too. One could reasonably write a test that connects an unbound channel, and expect that SM::checkListen is invoked. My intention was to use 8231570, in part, to examine the` @throws SecurityException` for receive. ( as well as what was mentioned above ) > The related issue that we touched on here is that > DatagramChannel.receive does not specify that it discards datagrams when > denied by the SM. I think we will need to adjust the wording for the > SecurityException. DatagramChannel::receive has the following @throws: * @throws SecurityException * If a security manager has been installed * and it does not permit datagrams to be accepted * from the datagram's sender This is incorrect. The specification should say that denied datagram packets will be discarded **. The only possible "fix" here, ignoring implicit bind since that will be handled by 8231570, is to remove the @throws ( as well as adding some spec verbiage, which is already implicit through the link to DatagramSocket ). But it might be prudent to not remove @throws yet, given 8231570 is still unresolved. 8231570 can be used to "fix" the @throws, to either 1) remove it, or 2) modify it to say that the bind may throw. I don't have a strong opinion either way which JIRA issue is used for which parts of the change, just that the changes happen without removing and re-adding an @throws -Chris. ** If registered with a selector for OP_READ, after waking up that selector then discarding the datagram. From brian.burkhalter at oracle.com Mon Sep 30 18:43:09 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 30 Sep 2019 11:43:09 -0700 Subject: [RFC] JDK-8162520: (fs) FileStore should support file stores with > Long.MAX_VALUE capacity In-Reply-To: <49606851-5b61-6913-0e22-654e4368ad93@oracle.com> References: <49606851-5b61-6913-0e22-654e4368ad93@oracle.com> Message-ID: > On Sep 28, 2019, at 9:07 AM, Alan Bateman wrote: > > On 27/09/2019 22:02, Brian Burkhalter wrote: >> : >> >> 1. Return the number of blocks of each type >> >> long getTotalBlocks(); >> long getUnallocatedBlocks(); >> long getUsableBlocks(); >> >> The respective sizes in whichever units can then be computed by the caller using the value returned by getBlockSize(). > This option does fit with the recently added getBlockSize, I just wonder if 2^63 blocks is enough. The native APIs seem to allow up to 2^64 (unsigned). I?m not sure what can be done aside from using an alternate representation instead of a long. The product of getTotalBlocks() and getBlockSize() would give a very large range of values. Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: