KMZ methods produce bad ZIP files

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Create a KML file that contains a placemark pointing to a custom icon 
(relative path)
2. using KmzFile static methods (any of them, but CreateFromKmlFilepath is 
easiest) convert the KML file & custom icon into a KMZ
3. Open in Google Earth -- icon is not displayed (broken link)

IMPORTANT NOTE:
If you leave the created KMZ next to the KML file from which it was created, 
and the custom icon exists locally near the file, it will APPEAR to work. 
Delete the custom icon, and it will stop working. Even if it works, however, 
you can verify it by clicking on the placemark in GE and selecting Properties 
(or 'Get Info' on Mac), then clicking on the icon button. If working properly, 
the path should include the name of the KMZ as if it were a directory (e.g. 
'/home/user/test.kmz/images/icon.png'). If it does not, it's not looking in the 
KMZ, probably because it couldn't read it properly (the earlier example, if not 
working, would look like '/home/user/images/icon.png' -- note the absence of 
the KMZ file in the path)

What is the expected output? What do you see instead?

I expect a KMZ that is a valid ZIP file and the icon should appear properly in 
Google Earth. Instead, I see a broken image link.

What version of the product are you using? On what operating system?

1.2.0, this happens on both Mac & Windows.

Did you run the unit test suite that comes with the project? Did all tests pass?

No, I haven't run the unit test suite. We have been using libkml with for a 
couple of years now without a problem.

Please provide any additional information below.

The KMZ produced, when renamed .zip, opens fine on Windows, though 'Modified 
By' is empty (odd). On Mac, if you try and open it in the Finder, it starts 
what is known as the 'gczip cycle'. You get filename.gczip after 
double-clicking. Double-clicking *that* gets you filename1.zip, and after that, 
filename1.gczip, etc.

You can unzip it manually from the command line using unzip, and it works. But 
the file dates are all from 1971 (probably a zero datestamp).

If we take file contents and create a ZIP file from scratch ourselves, then 
rename it .kmz, Google Earth has no problems reading it. So it seems to be some 
by-product of either minizip, or the way minizip is being used.

I've attached a simple sample data to use in the steps above. Point libkml at 
the .kml and run KmzFile::CreateFromKmlFilepath() on it. Then delete the images 
folder and run the kmz with GE -- you should see six broken image placeholders. 
If you take the attached ZIP file and just rename .kmz though, it will work.

Original issue reported on code.google.com by ajpatter...@gmail.com on 7 Jul 2011 at 6:29

Attachments:

• bug.zip

[GoogleCodeExporter]

Sorry, minor correction: the 'cycle' isn't 'gczip', its 'cpgz' If you google 
'cpgz cycle' you'll see a explanation of the phenomenon.

Original comment by ajpatter...@gmail.com on 7 Jul 2011 at 6:34

[GoogleCodeExporter]

I played around with your unit test data -- there's no project using the zip 
test unit data in 1.2.0 BTW (though its not hard to make one) -- and I was able 
to duplicate the problem by unzipping testdata/kmz/zermatt-photo.kmz and 
running CreateFromKmlFilepath() on the doc.kml. The result is a KMZ that looks 
valid -- you can rename it to .ZIP and see its contents -- but Google Earth 
will fail to find the image inside it. It also still fails to open properly 
when renamed to .zip on the Mac (cpgz cycle alluded to in earlier comment).

It's worth noting that for whatever reason, Google Earth is capable of finding 
the root level KML in the produced KMZ; it seems to just be unable to find 
things in sub-folders within the KMZ.

Original comment by ajpatter...@gmail.com on 8 Jul 2011 at 2:32

[GoogleCodeExporter]

One last note: I tried flattening the contents and that worked. The problem 
seems to be entirely with sub-folders. I've attached another KMZ, also produced 
with KmzFile::CreateFromKmlFilepath(), but this one works. The difference is 
all the images referenced are in the root folder of the ZIP file.

Original comment by ajpatter...@gmail.com on 8 Jul 2011 at 2:42

Attachments:

• output.kmz