<div dir="ltr"><div>Alan,</div><div><br></div><div>ZipOutputStream is a relatively high-level API for producing ZIP files. There are many shapes and corner cases allowed by APPNOTE.TXT which ZipOutputStream has no means to produce. So while exposing the "external file attributes" field (which was incorrectly named "extraAttributes" in ZipEntry) is perhaps not harmful in itself, the question is: Where do we stop?</div><div><br></div><div>It's worth noting that the ZipFileSystem API has the "enablePosixFileAttributes" env option which lets you set POSIX permissions on ZIP file entries using Files.setPosixFilePermissions()</div><div><br></div><div>The following OpenJDK test can serve as an example:</div><div><br></div><div><a href="https://github.com/openjdk/jdk/blob/master/test/jdk/sun/security/tools/jarsigner/PosixPermissionsTest.java#L151">https://github.com/openjdk/jdk/blob/master/test/jdk/sun/security/tools/jarsigner/PosixPermissionsTest.java#L151</a><br></div><div><br></div><div>Cheers,</div><div>Eirik,</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Dec 12, 2023 at 9:17 PM Alan Snyder <<a href="mailto:javalists@cbfiddle.com">javalists@cbfiddle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">ZipEntry is a public class and I am aware that it is used outside the JDK. Presumably that is not a problem.<br>
<br>
I’m wondering why the class stores the external file attributes field but does not provide public accessors for it.<br>
<br>
I would find it useful to have access to this field. I would rather not have to switch to using a third party library just for this reason.<br>
<br>
I understand that the interpretation of the external file attributes is not standardized, but the field itself is defined in the standard<br>
cited by the package info page, so I don’t see the harm in making it accessible without interpretation.<br>
<br>
  Alan<br>
<br>
<br>
<br>
</blockquote></div></div>