tracker issue : CF-4017002

select a category, or use search below
(searches all categories and all time range)
Title:

cfzip does not provide compressed size in local file header

| View in Tracker

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:

Am unable to repro the issue. I created a zipped folder using cfzip tag, then through HEX editor when opened, the bytes at address as mentioned in bug did not match. At address 7 value is 00 and value of bytes at 12-15 did not match with bytes at 5-8. This was tested on ColdFusion 11 + Update5 environment. Please provide more information to repro the case. Are all byte details that you have mentioned pertaining to line number 1? Do let us know. Thanks, Akhila.
Comment by Akhila K.
6777 | July 10, 2015 01:28:44 AM GMT
Using CF 11 update 5 execute the following code: <cfset local.dir = getTempDirectory() & "testZip/" /> <cfdirectory action="create" directory="#local.dir#" /> <cfset local.file = gettempFile(local.dir,"zipMe") /> <cffile action="write" file="#local.file#" output="1234" /> <cfoutput>#local.dir#</cfoutput> <cfzip action="zip" file="#local.dir#test.zip" source="#local.dir#" /> <cffile action="readbinary" file="#local.dir#test.zip" variable="zipFile" /> <cfdump var="#BinaryEncode(zipFile, 'Hex')#" /> the result is: C:\ColdFusion11\cfusion\runtime\work\Catalina\localhost\tmp\testZip/ 504B03041400080008009568EA460000000000000000060000001C0000007A69704D65323937313634373332393633333536363531362E746D7033343236E1E50200504B07081D1382310800000006000000504B010214001400080008009568EA461D13823108000000060000001C00000000000000000000000000000000007A69704D65323937313634373332393633333536363531362E746D70504B050600000000010001004A000000520000000000 --------------AA--------------------BBBBBBBBDDDDDDDD------------------------------------------------------------------------------------------------CCCCCCCC AA is the location of the general purpose bit flag in the local file header. if AA is 00, BBBBBBBB, the compressed size, should be equal to CCCCCCCC in the Data descriptor. if AA is 08, then DDDDDDDD should be 00000000
Comment by External U.
6778 | July 10, 2015 01:58:51 PM GMT
Breaking the file up into its parts: (copy and paste into an editor using a fixed width font) 504B0304 local file header signature 1400 version needed to extract 0800 general purpose bit flag 0800 compression method 9568 last mod file time EA46 last mod file date 00000000 crc-32 00000000 compressed size 06000000 uncompressed size 1C00 file name length 0000 extra field length 7A69704D65323937313634373332393633333536363531362E746D70 file name extra field DVA3P-33343236E1E50200 file data 504B0708 data descriptor signature 1D138231 crc-32 08000000 compressed size 06000000 uncompressed size 504B0102 central file header signature 1400 version made by 1400 version needed to extract 0800 general purpose bit flag 0800 compression method 9568 last mod file time EA46 last mod file date 1D138231 crc-32 08000000 compressed size 06000000 uncompressed size 1C00 file name length 0000 extra field length 0000 file comment length 0000 disk number start 0000 internal file attributes 00000000 external file attributes 00000000 relative offset of local header 7A69704D65323937313634373332393633333536363531362E746D70 file name extra field file comment 504B0506 end of central dir signature 0000 number of this disk 0000 number of the disk with the start of the central directory 0100 total number of entries in the central directory on this disk 0100 total number of entries in the central directory 4A000000 size of the central directory 52000000 offset of start of central directory with respect to the starting disk number 0000 .ZIP file comment length .ZIP file comment Because the general purpose bit flag is 0800, the compressed size in the local file header, data descriptor, and central file header should all match, but the local file header value is different, thus the problem.
Comment by External U.
6779 | July 10, 2015 02:32:06 PM GMT
We are using third party library to leverage this functionality. We have raised this issue with them and are waiting for a response. WIll include the fix once they response back to us. Thanks Subir
Comment by Subir J.
6780 | October 30, 2015 03:11:31 AM GMT
If there is a new version of zip4j library, then we will upgrade the jars.
Comment by HariKrishna K.
6781 | July 13, 2017 08:05:04 AM GMT