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 j.u.zip evolution is hard.
On Wed, Sep 12, 2018 at 7:44 AM, Langer, Christoph <christoph.lan...@sap.com> wrote: > Hi all, > > 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 [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 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 [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 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 > Christoph > > [1] https://bugs.openjdk.java.net/browse/JDK-6194856 > [2] http://www.info-zip.org/doc/appnote-19970311-iz.zip >
