Re-iterate JDK-6194856: Zip Files lose ALL ownership and permissions of the files

Martin Buchholz martinrb at
Wed Sep 12 16:18:43 UTC 2018

In principle I support making system specific extensions to the ZIP
spec more supported, as other zip implementations do.  There is long
standing tension between Java trying to be highly portable and
providing access to the data you need.  It's already the case that
some implementation bits are not exposed but the zip implementation
handles it "magically" under the covers, e.g. IIRC the utf-8 bit.
There is also tension between ZipEntry as just a mutable struct and a
read-only interface to an existing zip file.  Performance of zip
implementations is critical so one would like to do lazy lookup.
Coming up with a good design for evolution is hard.

On Wed, Sep 12, 2018 at 7:44 AM, Langer, Christoph
<christoph.langer at> wrote:
> Hi all,
> I'm currently revisiting a long standing shortcoming of the (and java.util.jar) implementation.
> The lack is that in the current implementation, Unix mode bits (e.g. rwx) are not stored/read from zip or jar files and the jar tool has no capabilities to store/preserve the mode information. There have been several bugs opened but they were closed with "Won't Fix". One of them is JDK-6194856, mentioned in this mail's subject [1]. Unfortunately there is no detailed reasoning given why that can't be done. Maybe these are compatibility or security issues? Maybe someone can enlighten me about previous discussions concerning this matter...
> I personally can imagine contributing the following:
> First step: Enrich with some method(s) like getUnixPermissions() and setUnixPermissions().
> For writing zip files it would mean depending on the availability of Unix permission information in a ZipEntry object, the entry version would be set to "3 - Unix" according to section "D.  Explanation of fields", "version made by (2 bytes)" of the zip specification that is referenced in the current Javadoc for the package [2].
> Reading Zip files would take into account the file attribute mapping of the version field and in case of "3 - Unix", it would read the permissions settings from the external file attributes section of the entry header.
> This seems to be the de-facto standard of the GNU zip/unzip implementation.
> With that addition the the API, developers using it would get the ability to cope with Unix permissions.
> As a second step, I can imagine spending a flag for the jar utility to have it handle Unix permissions when packing/extracting.
> Isn't that something that should be done? Or, if not, why?
> Thanks and best regards in advance
> Christoph
> [1]
> [2]

More information about the core-libs-dev mailing list