It's hard to get the ZipEntry API right to perfectly handle these
platform specific
"file system attributes" especially given the potential performance and
security
concern.
I would assume zipfs might be a better place to handle this if "really"
desired,
in which already has the base to handle "file attributes". We can have a
zipfs
based jar/zip somewhere to take advantage of its file system nature. For
example, start from "open/test/jdk/jdk/nio/zipfs/Demo.java" :-)
-Sherman
On 9/12/18, 9:18 AM, Martin Buchholz wrote:
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
