Status/Resolution/Reason: Closed/Won't Fix/ThirdParty
Reporter/Name(from Bugbase): Bryan Henderson / Bryan Henderson (Bryan Henderson)
Created: 07/06/2015
Components: File Management
Versions: 11.0
Failure Type:
Found In Build/Fixed In Build: CF11_Final /
Priority/Frequency: Normal / All users will encounter
Locale/System: ALL / Windows 7 64-bit
Vote Count: 0
Problem Description: the compressed size value in the local file header for each file in a zip archive is set to 0, causing a mismatch with the compressed size of the file in the central file header (preventing some applications from using the zip file.)
The PKZIP Specification (found at https://pkware.cachefly.net/webdocs/casestudies/APPNOTE.TXT) indicates that the local file header should contain the correct compressed size that is matched with the central file header compressed size for the file OR the general purpose bit flag bit #3 should be set indicating that BOTH the compressed size and uncompressed size in the local file header will be set to 0 and that the data descriptor following the compressed data should be used to find the values.
CF10 sets the general purpose bit flag bit #3 and leaves both compressed and uncompressed sizes as 0.
Steps to Reproduce: create a zip archive file with the cfzip tag and inspect its contents in a HEX editor. inspect byte at address 7 (which will be 00 instead of 08, general purpose bit flag bit #3 not set) and inspect bytes 12 - 15 (which will all be 00, but should indicate the compressed size of the file, matching bytes 5-8 after the sequence 50 4B 07 08, which indicates the beginning of the data descriptor at the end of the included file in the archive.)
Actual Result: the local file header compressed size is set to 0 and the general purpose bit flag bit #3 is not set. The local file header uncompressed size has a value, indicating that compressed size should also have a value.
Expected Result: the local file header should either have the correct compressed size value OR the general purpose bit flag bit #3 should be set to indicate that BOTH the compressed size and uncompressed size will be set to 0 and that their values should be found in the data descriptor following the compressed data. (similar to how CF10 works.)
Any Workarounds: use of third party software to create the zip file with CFEXECUTE tag.
Use JAVA: an example to create a zip archive is below...
<cffunction name="zip">
<cfargument name="file" />
<cfargument name="source" />
<cfset byteClass = createObject("java", "java.lang.Byte").TYPE />
<cfset buffer = createObject("java","java.lang.reflect.Array").newInstance(byteClass, 2048) />
<cfset fos = createObject("java","java.io.FileOutputStream").init(arguments.file) />
<cfset zos = createObject("java", "java.util.zip.ZipOutputStream").init(fos) />
<cfdirectory action="list" directory="#arguments.source#" name="dir" />
<cfloop query="dir">
<cfset ze = createObject("java", "java.util.zip.ZipEntry").init(dir.name) />
<cfset zos.putNextEntry(ze) />
<cfset fis = createObject("java","java.io.FileInputStream").init(dir.directory & "\" & dir.name) />
<cfloop condition="true">
<cfset len = fis.read(buffer) />
<cfif len LTE 0><cfbreak /></cfif>
<cfset zos.write(buffer, 0, len) />
</cfloop>
<cfset fis.close() />
<cfset zos.closeEntry() />
</cfloop>
<cfset zos.close() />
</cffunction>
----------------------------- Additional Watson Details -----------------------------
Watson Bug ID: 4017002
External Customer Info:
External Company:
External Customer Name: Bryan
External Customer Email:
External Test Config: My Hardware and Environment details: DELL Precision M6700, CF 11
Attachments:
Comments: