Re-iterate JDK-6194856: Zip Files lose ALL ownership and permissions of the files
christoph.langer at sap.com
Wed Sep 12 14:44:59 UTC 2018
I'm currently revisiting a long standing shortcoming of the java.util.zip (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 . 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 java.util.zip.ZipEntry 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 java.util.zip package .
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 java.util.zip 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
More information about the core-libs-dev