Zip-cpgz loop on Mac OS X

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Open Chrome on Mac OS and connect to Orthanc Explorer
2. Download a ZIP file with Orthanc Explorer
3. After downloading, the zip extracts to a .cpgz file, leading to a zip-cpgz 
loop

What is the expected output? What do you see instead?
The ZIP file should uncompress.

Please use labels and text to provide additional information.
The problem does not occur with Safari. However, OsiriX still cannot access the 
uncompressed files (cf. attached screenshot).
The symptom is described here: 
http://osxdaily.com/2013/02/13/open-zip-cpgz-file/
See also: 
https://groups.google.com/forum/?hl=fr#!topic/orthanc-users/Ss_2bSpK8IY

Original issue reported on code.google.com by s.jodo...@gmail.com on 27 Aug 2013 at 6:46

Attachments:

• OsiriX-Orthanc-03.png

[GoogleCodeExporter]

Unfortunately, I do not have access to a Mac computer (cf. issue #1), so I 
cannot help currently. Does anybody have an idea to fix this problem?

Original comment by s.jodo...@gmail.com on 27 Aug 2013 at 6:47

[GoogleCodeExporter]

One solution for the problem.
Select the study and in the context menu, select the option "Decompress DICOM 
files".

Original comment by vinic...@terradigital.com.br on 28 Aug 2013 at 3:52

Attachments:

• OsiriX-decompress-01.png

[GoogleCodeExporter]

It seems to be an issue with Mac OS Finder and ZIP64 support. Orthanc 
compresses the files using ZIP64, which was introduced in PKZIP v4.5 [1] to 
overcome certain limitations (4GB file size, etc.) [2]. Finder can not 
uncompress these files, external applications like "The Unarchiver", or unzip 
do work. Downloading through Safari also works, because it automatically 
uncompresses the zip file.
The version of the zip file is set in the header on position 0x4 [3]. Versions 
0x0A and 0x14 work ok, 0x2D = v4.5 does not.
When the zipOpen64 function from zlib is used, the header is set to 0x2D, after 
changing the function to zipOpen, the header is set to 0x14, and Finder opens 
the archive correctly.
If the 4GB size and 65535 entry number is not limiting, than the patch should 
solve the problem. Otherwise, the correct method has to be selected based on 
the file size and count.

[1] https://en.wikipedia.org/wiki/PKZIP#PKZIP
[2] https://en.wikipedia.org/wiki/ZIP_(file_format)#ZIP64
[3] https://users.cs.jmu.edu/buchhofp/forensics/formats/pkzip.html

Original comment by peter.so...@gmail.com on 30 Aug 2013 at 12:56

Attachments:

• zip64_patch.diff

[GoogleCodeExporter]

Hi Peter,
Thank you very much for this explanation! I have added a Trello card to include 
your patch:
https://trello.com/c/loSStcWD

Original comment by s.jodo...@gmail.com on 30 Aug 2013 at 6:25

[GoogleCodeExporter]

Great job Peter!
I'll apply the patch and test.

Thanks!

Original comment by vinic...@terradigital.com.br on 30 Aug 2013 at 11:40

[GoogleCodeExporter]

Dear Peter,

I have just submitted the "correct" method into the mainline (that determines 
whether ZIP64 must be used depending on the file size and count):
https://code.google.com/p/orthanc/source/detail?r=fb49bf72ac2d8317cb2a51d8ada667
964241b218

Vinicius, could you test whether your Mac OS problem is solved in the mainline 
of Orthanc?

These modifications will be part of Orthanc 0.7.1.

Original comment by s.jodo...@gmail.com on 30 Oct 2013 at 8:02

• Changed state: Started

[GoogleCodeExporter]

Orthanc 0.7.1 has been released. Please someone using a Mac OS client check 
that this release fixes the bug? Thanks!

Original comment by s.jodo...@gmail.com on 1 Nov 2013 at 11:20

[GoogleCodeExporter]

I confirm that Orthanc 0.8.1 does not exhibit this issue anymore. I close now 
the bug. Do not hesitate to reactivate it if the problem still occurs.

Original comment by s.jodo...@gmail.com on 4 Aug 2014 at 12:15

• Changed state: Fixed