JDK-6194856 : Zip Files lose ALL ownership and permissions of the files
  • Type: Enhancement
  • Component: core-libs
  • Sub-Component: java.util.jar
  • Affected Version: 8.1ee,1.1.1,1.2.0,1.3.0,1.4.0,5.0,6
  • Priority: P3
  • Status: Resolved
  • Resolution: Duplicate
  • OS:
    generic,solaris,solaris_2.5.1,solaris_2.6 generic,solaris,solaris_2.5.1,solaris_2.6
  • CPU: generic,unknown,x86,sparc
  • Submitted: 2004-11-12
  • Updated: 2023-10-17
  • Resolved: 2023-10-17
Related Reports
Duplicate :  
JDK-4171369 - unzip will mask off execute bit off of files/directories in jar file
Duplicate :  
JDK-6727834 - jar does not preserve permissions
Duplicate :  
JDK-4931799 - file executable permission is lost when extracting from jar file
Duplicate :  
JDK-6299847 - jar uvf commands doesn't restore group permission when updated with root user.
Duplicate :  
JDK-4097578 - Enhance jar tool to preserve file permissions/modes
Duplicate :  
JDK-8213031 - (zipfs) Add support for POSIX file permissions
Relates :  
JDK-8213031 - (zipfs) Add support for POSIX file permissions
Description
If you do the following:

- create a zip file containing some files
- delete the original files
- restore the files from the zip

Results:
All of the original permissions and ownership have changed to:
owner: whomever did the restore
permissions: whatever the umask calls for (on UNIX)

IMHO it is a HUGE problem that the JDK uses a least-common-denominator approach to java.io  I.e. no permissions or ownership support!


###@###.### 2004-11-12 20:46:11 GMT
Comments
Sure. This has been more or less solved, respectively a viable alternative via zipfs has been provided with JDK-8213031.
17-10-2023
Christoph, Five years has passed, the discussion you mentioned when reopening this issue seem to never have materialized. Would it be fair to close this again as "Will not fix"?
16-10-2023
I'm reopening this ticket to propose/discuss enhancements.
25-09-2018
will not fix.
28-08-2015
EVALUATION From evaluationa of 4931799 and 6299847: The "standard" zip file format does not have any way to store "executable file" meta-information, since it was originally designed for MS-DOS filesystems. In order to preserve Unix information like file modes, the zip handling code would have to handle extensions to the zip file format. Other zip implementations have such extensions. There are some extensions to the file format that would allow maintaining this kind of information, but it can never be guaranteed (there is no requirement that zip files contain such "extended" metadata) and it would be a lot of work to implement and (especially!) test. We should support those extensions.
14-12-2006
WORK AROUND Try your luck with other zip implementations.
02-04-2006
EVALUATION It's not so easy to get this right, even if we don't care about backward compatibility. Only root can restore ownership. There is some more permission control added in mustang, but still not full control over permissions like Unix "chmod". The zip file format does not include ownership/permission information in its standard form, but does include it in its Unix-specific extensions, which are more-or-less standard.
02-04-2006
EVALUATION RFE - not for 8.1 UR1, reevaluate for 9.0. ###@###.### 2005-03-07 20:14:58 GMT
07-03-2005
SUGGESTED FIX Thorough Fix: When creating a zip -- get the permissions and ownership for every file and save this information to a standardized "permissions-file" inside the zip. After restoring everything -- set the permissions and ownership for every file based on the information in the "permissions-file". This is a LOT of work. It should be globally available as a subclass of the JDK zip file classes -- e.g. ZipFileWithPermissions -- so that it is transparent to users. ###@###.### 2004-11-12 20:48:36 GMT ###@###.### 2004-11-12 20:49:40 GMT
12-11-2004