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.
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?
(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.
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.
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.
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
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.
releated to #42122 maybe?
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