tracker issue : CF-3117486

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

CFZIP and CFFILE cannot read archives containing stored files with exotic characters in their names

| View in Tracker

Status/Resolution/Reason: Closed/Deferred/ThirdParty

Reporter/Name(from Bugbase): Ari-Ville Fernelius / Ari-Ville Fernelius (Fernis)

Created: 02/17/2012

Components: File Management, CFFile

Versions: 10.0

Failure Type: Non Functioning

Found In Build/Fixed In Build: Public Beta /

Priority/Frequency: Normal / Some users will encounter

Locale/System: English / Win 2008 Server R2 64 bit

Vote Count: 0

Problem Description:

Originally this problem scenario started with me wanting to enable users uploading fles larger than 4GB on the server. I programmed a feature where users can upload multipart/split zip archives, and ColdFusion would then extract the zip content. However, this turned out not to work anything like expected, as none of the file names in the zip archive can contain any european accented characters or other exotic stuff.

ColdFusion cannot however handle at all any zip files which have files inside with names like "lé fu.txt" (accents etc on the top of the characters). Thus it's impossible to even rename the uploaded zip file content, as ColdFusion cannot handle the zip files at all. This applies to ColdFusion 9 and ColdFusion 10 beta.

Steps to Reproduce:

1. Create a zip file called
2. Add a file inside the zip file, which has an exotic character in the file name (é, è, á, à, etc.)
3. Try to read the file with  CFZIP (ColdFusion 9 and 10) 
4. Try to read the with CFDIRECTORY using the new zip: file support (ColdFusion 10)

<cfzip action="list" file="#expandpath('./')" name="result"> (with ColdFusion 9 or 10)
<cfdirectory action="list"  directory="zip:#expandpath('./')#/" name="result"> (with ColdFusion 10)

The cfzip fails completely on all ColdFusion versions. 
The cfdirectory on ColdFusion 10 seems to work, but fails to show the correct result for file names.
For example, if the zip has a file called vr4_final_utfé" the cfdump result shows "vr4_final_utf[]" - the last T is missing!
This seems some buffer/utf-8 issue - the file name length of the file is understood incorrectly by CF.

Furthermore, even if we would magically know the correct file names inside the zip, CFFILE fails to extract the files in the archive.
<cffile action="read" file="zip:#expandpath('./')#/!/vr4_final_utfé" variable="result">

Actual Result:

ColdFusion server returns error.

Expected Result:

Any Workarounds:

With ColdFusion 9, no workaround exists. The zip content cannot be read.
With ColdFusion 10 beta, no workaround exists either. The ZIP file content can be read, but with incorrect results. And there is no way to extract the files, as CFFILE fails.

With both CF9 and CF10beta, all methods of handling ZIP files basically fail when there's a great chance of zip archive contents using european/exotic characters.

----------------------------- Additional Watson Details -----------------------------

Watson Bug ID:	3117486

External Customer Info:
External Company:  
External Customer Name: Fernis
External Customer Email:  
External Test Config: My Hardware and Environment details:

Windows Server 2008R2, CF9.0.1 single instance, IIS7.5, English system language

Windows Vista x64 SP2, CF10 beta single istance, built-in web server, English system language



This should be a bug in Java because we use ZipFile/ZipEntry for this. We can't do anything if Java does not give the correct file name.
Comment by Rupesh K.
20783 | February 22, 2012 08:38:02 AM GMT
"Should be a bug in Java" or "*is* a bug in Java"? Did you reproduce it using the Java libs directly? Have you got a repro case demonstrating it (please attach)? Have you proven it's not a matter of you using the lib incorrectly? Are you handling the charset correctly? And given all this, have you raised a ticket with Oracle (link?)? How is it it *kinda* works with <cfdirectory> but not at all with <cfzip>? Does using the Java lib directly behave in this way as well?
Comment by External U.
20784 | October 26, 2015 05:01:29 AM GMT