Bug 34764 - Zip task sets '000' permission on UNIX
Summary: Zip task sets '000' permission on UNIX
Status: RESOLVED FIXED
Alias: None
Product: Ant
Classification: Unclassified
Component: Core tasks (show other bugs)
Version: 1.6.0
Hardware: Other Linux
: P2 normal (vote)
Target Milestone: 1.8.0
Assignee: Ant Notifications List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-05-05 17:38 UTC by Chun Shi
Modified: 2008-07-18 03:21 UTC (History)
3 users (show)



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Chun Shi 2005-05-05 17:38:38 UTC
Recently, we upgraded ANT from 1.5.3 to 1.6.2. However, I've encountered
permission issue in following scenario:
  - A jar file is built on Windows
  - This jar file is merged into another jar file via zipfileset on Linux or Solaris
  - Extract the jar file built in 2nd step using unzip by Info-ZIP

All entries from the jar file built on Windows have '000' permission. As a
result, they are inaccessible.
Comment 1 Steve Loughran 2005-05-05 18:05:30 UTC
There are no unix file permissions in Jar files; they are like zip files: DOS only.

1. what non-standard field is info-zip using for storing its permissions?
2. what happens when you unzip using other popular tools?
Comment 2 Chun Shi 2005-05-05 18:35:01 UTC
(In reply to comment #1)
> There are no unix file permissions in Jar files; they are like zip files: DOS 
only.
> 1. what non-standard field is info-zip using for storing its permissions?
> 2. what happens when you unzip using other popular tools?

Well, according to ANT's source code, it's the jar task extended from zip task 
to set the permission on an entry, no matter if you build a jar file or zip 
file.

For the questions you asked, I don't have the answers. Sorry.
Comment 3 Steve Loughran 2005-05-06 12:25:39 UTC
oh, i see, yes, it is at the bottom. I hadn't noticed that. Thank you for your
correction.

-are the original JAR file permissions ok, but the merged ones broken?
-did this work before?

As usual, try Ant1.6.3 to see if this changes anything. In this case I doubt it,
but it's the first step to fixing things.

We are going to have some fun writing a test case for this problem. 
Comment 4 Stefan Bodewig 2005-07-08 16:20:53 UTC
jar files generated by the JDK's jar tool in general have broken permissions when
extracted by InfoZIP's unzip (the directories are not executable).  This was
the main reason that made us implement our own Zip*Stream and ZipEntry classes
- adding support for filemode and dirmode.

Steve, the permissions are stored inside the external attributes of the zip entry,
you can access them via Ant's ZipEntry class.

OK, how do you create the jar file on Windows?  How do the permissions look
like if you run unzip on the jar created in the first step?

Your <zipfileset> probably has neither a filemode nor a dirmode attribute,
in which case it later on you don't get the default permissions (0744 and 0755
respectively) but whatever the external attributes in the first jar said.
Comment 5 Mark Chappell 2005-08-30 17:08:30 UTC
I beleive that we may be seeing the same issue.

    104     <target name="client-inject-tlds">
    105         <echo message="Injecting TLDs into ${client.war.name}" />
    106         <!-- Something is broken in Ant's zip task 
    107                 It doesn't do zip updating properly it effectively unzips
    108                 then rezips the old contents into the new file, and
    109                 messes the permissions up in the process (Unix "0000")
    110             -->
    111         <move file="${client.war.name}" tofile="${client.war.name}.tmp" />
    112         <zip
    113                 destfile="${client.war.name}"
    114                 duplicate="fail"
    115                 >
    116             <zipfileset
    117                     src="${client.war.name}.tmp"
    118                     filemode="0744"
    119                     dirmode="0755"
    120                     />
    121             <zipfileset
    122                     dir="${client.dir.build.tld}"
    123                     prefix="WEB-INF/lib"
    124                     filemode="0744"
    125                     dirmode="0755"
    126                     />
    127         </zip>
    128         <delete file="${client.war.name}.tmp" />
    129         <!-- this should work but doesn't... 
    130         <zip
    131                 destfile="${client.war.name}"
    132                 duplicate="fail"
    133                 update="true"
    134                 keepcompression="true"
    135                 >
    136             <zipfileset
    137                     dir="${client.dir.build.tld}"
    138                     prefix="WEB-INF/lib"
    139                     filemode="0744"
    140                     dirmode="0755"
    141                     />
    142         </zip>
    143         -->
    144     </target>

The commented out version at the bottom produces
d---------    2 nslm     users          80 Aug 30 14:28 META-INF
drwxr-xr-x    4 nslm     users         288 Aug 30 14:28 WEB-INF
----------    1 nslm     users        3311 Jul 25 09:32 advancedSearch.jsp

Where as the kludged version at the top produces
drwxr-xr-x    2 nslm     users          80 Aug 30 15:23 META-INF
drwxr-xr-x    4 nslm     users         288 Aug 30 15:23 WEB-INF
-rwxr--r--    1 nslm     users        3311 Jul 25 09:32 advancedSearch.jsp


META-INF and advancedSearch are in ${client.war.name}

It would appear that in "preserving" the contents of the original file you are
dropping the permissions associated with the existing entries.  I can see no way
to reset said permissions as suggested by Stefan, since it is the file we are
attempting to merge things into which is being corrupted. ${client.war.name} was
also created through ant during the same build sequence.

This is also with ant 1.6.2
Comment 6 Mark Chappell 2005-08-30 17:10:51 UTC
I've just realised I didn't mention that the file which is being messed up looks
fine if unzipped before the zip task is run.
Comment 7 Kostas Georgiou 2008-04-09 17:17:46 UTC
releated to #42122 maybe?
Comment 8 Stefan Bodewig 2008-07-18 03:21:32 UTC
svn revision 677871 contains a testcase for the update case which passes, this has probably been fixed as a side effect of fixing bug 42122