<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Hi Christoph<br class=""><div><blockquote type="cite" class=""><div class="">On Jan 12, 2019, at 8:02 AM, Langer, Christoph <<a href="mailto:christoph.langer@sap.com" class="">christoph.langer@sap.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">Hi Alan,<br class=""><br class="">as I did not hear back from you I continued to work on the POSIX file permission support for zipfs and specified/implemented the value of 'null' for zip entries with no permission information associated (vs. UnsupportedOperationException).<br class=""><br class="">I updated the CSR: <a href="https://bugs.openjdk.java.net/browse/JDK-8213082" class="">https://bugs.openjdk.java.net/browse/JDK-8213082</a><br class="">And here is an updated webrev for the change: <a href="http://cr.openjdk.java.net/~clanger/webrevs/8213031.5/" class="">http://cr.openjdk.java.net/~clanger/webrevs/8213031.5/</a><br class=""><br class="">I also changed the first part of the module-info documentation for jdk.zipfs, mentioning the URI scheme 'jar' and corrected the information about how the zip file system provider can be accessed and new zip filesystems can be</div></div></blockquote><blockquote type="cite" class=""><div class=""><div class="">created.<br class=""></div></div></blockquote><div><br class=""></div>I think the above should be addressed via JDK-8182117 which I will be addressing and keep this focused on the POSIX file permission enhancements as I think it should be in its own CSR.</div><div><br class=""></div><div>Best</div><div>Lance<br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class="">Please kindly review this.<br class=""><br class="">Thank you and best regards<br class="">Christoph<br class=""><br class=""><blockquote type="cite" class="">-----Original Message-----<br class="">From: Langer, Christoph<br class="">Sent: Dienstag, 8. Januar 2019 09:27<br class="">To: 'Alan Bateman' <<a href="mailto:Alan.Bateman@oracle.com" class="">Alan.Bateman@oracle.com</a>>; Volker Simonis<br class=""><<a href="mailto:volker.simonis@gmail.com" class="">volker.simonis@gmail.com</a>><br class="">Cc: nio-dev <<a href="mailto:nio-dev@openjdk.java.net" class="">nio-dev@openjdk.java.net</a>>; OpenJDK Dev list <security-<br class=""><a href="mailto:dev@openjdk.java.net" class="">dev@openjdk.java.net</a>>; Java Core Libs <<a href="mailto:core-libs-dev@openjdk.java.net" class="">core-libs-dev@openjdk.java.net</a>><br class="">Subject: RE: RFR 8213031: (zipfs) Add support for POSIX file permissions<br class=""><br class="">Hi Alan, Volker,<br class=""><br class="">thanks for bringing up these discussion points. I agree that we shall carefully<br class="">revisit that.<br class=""><br class="">First of all, I'd like to point out that PosixFileAttributeView::readAttributes<br class="">won't ever throw UOE with the proposed changes to zipfs. It should always<br class="">return an object of type PosixFileAttributes which will be an incarnation of<br class="">ZipFileSystem.Entry.<br class=""><br class="">The returned PosixFileAttributes(ZipFileSystem.Entry) object now<br class="">implements 3 additional methods: owner(), group() and permissions(). I can<br class="">see that UOE should only be thrown if something is not supported by an<br class="">implementation at all. So it perfectly fits to owner() and group() because this<br class="">is simply not implemented in zipfs (yet...). As for permissions, I then agree,<br class="">UOE probably isn't the right thing to do because permissions will now be<br class="">supported by zipfs.<br class="">Still, we need to distinguish between the case where no permission<br class="">information is present vs. an empty set of permissions that was explicitly<br class="">stored. You brought up IOException as an alternative. But I think this is not<br class="">really feasible for the following main reason: IOE is no RuntimeException, so<br class="">it has to be declared for a method when it is thrown.<br class="">PosixFileAttributes::permissions, however, does not declare IOE so far. And I<br class="">don't think we can/want to modify the PosixFileAttributes interface for the<br class="">sake of that zipfs implementation change.<br class=""><br class="">I think, we should look into using/returning null for "no permission<br class="">information present".<br class=""><br class="">With that, the point is: What happens if we pass null to another<br class="">PosixFileAttributeView::setPermissions implementation (or to<br class="">Files::setPosixFilePermissions, which ends up there). For zipfs, with the<br class="">proposed changeset, this would work perfectly fine. We translate the null<br class="">value into (int)-1 for the "posixPerms" field of "Entry" and will then not set<br class="">permission information in the zip file. But other places in the JDK that<br class="">implement PosixFileAttributeView need some rework. Those are:<br class="">src/java.base/unix/classes/sun/nio/fs/UnixFileAttributeViews.Posix<br class="">src/java.base/unix/classes/sun/nio/fs/UnixSecureDirectoryStream.PosixFile<br class="">AttributeViewImpl<br class=""><br class="">And we should amend the specs/doc for the following methods to define<br class="">the handling of the null value as a noop:<br class="">PosixFileAttributeView::setPermissions<br class="">PosixFileAttributes::permissions<br class="">Files::setPosixFilePermissions<br class="">Files::getPosixFilePermissions<br class=""><br class="">In the implementation I can see that we modify the aforementioned places<br class="">to handle null by translating it to (int)-1 in<br class="">UnixFileModeAttribute::toUnixMode and then using this value as noop in<br class="">'setMode' resp. 'fchmod'.<br class=""><br class="">Do you think this is the right way to go? Should we maybe do the spec<br class="">update of the permission methods in a separate change?<br class=""><br class="">Best regards<br class="">Christoph<br class=""><br class=""><blockquote type="cite" class="">-----Original Message-----<br class="">From: Alan Bateman <<a href="mailto:Alan.Bateman@oracle.com" class="">Alan.Bateman@oracle.com</a>><br class="">Sent: Montag, 7. Januar 2019 21:46<br class="">To: Volker Simonis <<a href="mailto:volker.simonis@gmail.com" class="">volker.simonis@gmail.com</a>><br class="">Cc: Langer, Christoph <<a href="mailto:christoph.langer@sap.com" class="">christoph.langer@sap.com</a>>; nio-dev <nio-<br class=""><a href="mailto:dev@openjdk.java.net" class="">dev@openjdk.java.net</a>>; OpenJDK Dev list <security-<br class=""><a href="mailto:dev@openjdk.java.net" class="">dev@openjdk.java.net</a>>; Java Core Libs <<a href="mailto:core-libs-dev@openjdk.java.net" class="">core-libs-dev@openjdk.java.net</a>><br class="">Subject: Re: RFR 8213031: (zipfs) Add support for POSIX file permissions<br class=""><br class="">On 07/01/2019 19:26, Volker Simonis wrote:<br class=""><blockquote type="cite" class="">:<br class="">We considered this, but it is problematic because it is perfectly<br class="">valid to have a file with external file attributes where none of the<br class="">Posix attributes is actually set (i.e. an empty set of Posix files<br class="">attributes). This wouldn't be distinguishable from the case where a<br class="">file has no external file attributes. So it seems we have to resort to<br class="">throwing an IOE?<br class=""><br class=""></blockquote>Maybe although it would be a bit awkward to deal with. The issues around<br class="">this remind me a bit about mounting fat32 file systems on Linux or Unix<br class="">systems where the fields in the stat structure are populated with<br class="">default values. PosixFileAttributeView::readAttributes is essentially<br class="">the equivalent of a stat call. This might be something to look at for<br class="">the file owner at least.<br class=""><br class="">-Alan<br class=""></blockquote></blockquote></div></div></blockquote></div><br class=""><div class="">
<div class=""><span class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px; "><span class="Apple-style-span" style="color: rgb(102, 102, 102); font-family: Verdana, Arial, Helvetica, sans-serif; font-size: small; "><a href="http://oracle.com/us/design/oracle-email-sig-198324.gif" class=""><span><img apple-inline="yes" id="08334E64-6053-48B8-B813-F869B5F6E8B8" src="cid:E1C4E2F0-ECD0-4C9D-ADB4-B16CA7BCB7FC@home" class=""></span></a><div style="color: rgb(0, 0, 0); font-family: Helvetica; font-size: medium; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; " class=""><a href="http://oracle.com/us/design/oracle-email-sig-198324.gif" class=""><span class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px; "><span class="Apple-style-span" style="color: rgb(102, 102, 102); font-family: Verdana, Arial, Helvetica, sans-serif; font-size: small; "></span></span></a><a href="http://oracle.com/us/design/oracle-email-sig-198324.gif" class=""><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; border-spacing: 0px; -webkit-text-decorations-in-effect: none; "><span class="Apple-style-span" style="color: rgb(102, 102, 102); font-family: Verdana, Arial, Helvetica, sans-serif; font-size: small; "><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; border-spacing: 0px; -webkit-text-decorations-in-effect: none; "></span></span></span></a><a href="http://oracle.com/us/design/oracle-email-sig-198324.gif" class=""><br class=""></a><span style="color: rgb(102, 102, 102); font-family: Verdana, Arial, Helvetica, sans-serif; font-size: small; " class="">Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037</span><br style="color: rgb(102, 102, 102); font-family: Verdana, Arial, Helvetica, sans-serif; font-size: small; " class=""><font color="#FF0000" style="font-family: Verdana, Arial, Helvetica, sans-serif; font-size: small; " class="">Oracle</font><span style="color: rgb(102, 102, 102); font-family: Verdana, Arial, Helvetica, sans-serif; font-size: small; " class=""> Java Engineering </span><br style="color: rgb(102, 102, 102); font-family: Verdana, Arial, Helvetica, sans-serif; font-size: small; " class=""><span style="color: rgb(102, 102, 102); font-family: Verdana, Arial, Helvetica, sans-serif; font-size: small; " class="">1 Network Drive </span><br style="color: rgb(102, 102, 102); font-family: Verdana, Arial, Helvetica, sans-serif; font-size: small; " class=""><span style="color: rgb(102, 102, 102); font-family: Verdana, Arial, Helvetica, sans-serif; font-size: small; " class="">Burlington, MA 01803</span><br style="color: rgb(102, 102, 102); font-family: Verdana, Arial, Helvetica, sans-serif; font-size: small; " class=""><a href="mailto:Lance.Andersen@oracle.com" style="font-family: Verdana, Arial, Helvetica, sans-serif; font-size: small; " class="">Lance.Andersen@oracle.com</a></div><div style="color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; " class=""><br class=""></div><br class="Apple-interchange-newline">
</span></span></div>
</div><br class=""></body></html>