by argv » Tue Sep 19, 2017 11:10 pm
A while back, Graf taught GZDoom how to load a zip archive where all the resources are inside a single, top-level folder. After struggling to figure out why
this Heretic mod wouldn't load, I discovered the cause.
As you know, most zip archivers place a separate entry in the zip's central directory for each folder, before the entries for the files in that folder. Because of this, FZipFile::Open assumes that, if there is a common prefix for every file in the archive, the name of the first entry will be that prefix.
That assumption doesn't always hold. In particular, for whatever reason, Bitbucket's zip generator does
not generate separate zip entries for folders. Info-ZIP and 7-Zip don't emit any error messages about such archives when testing or extracting them, so this kind of zip structure seems to be generally recognized as valid. But because it isn't what FZipFile::Open expects, GZDoom doesn't load it correctly.
The attached file contains two zip archives, both containing a replacement TITLEPIC, to demonstrate the problem. “bugdemo-works.zip” has zip entries for the folders, and GZDoom loads it correctly. “bugdemo-broken.zip” has been stripped of folder entries, and while it extracts successfully with normal zip tools, GZDoom does not load it correctly.
- Attachments
-
bugdemo.zip- Demonstration of the problem.
- (5.12 KiB) Downloaded 132 times
[url=https://forum.zdoom.org/viewtopic.php?f=18&t=53522]A while back[/url], Graf taught GZDoom how to load a zip archive where all the resources are inside a single, top-level folder. After struggling to figure out why [url=https://bitbucket.org/argv/brutal-heretic-rpg/get/d4b0ace006847a01f8c2569ab43be6c95e97ac6d.zip]this Heretic mod[/url] wouldn't load, I discovered the cause.
As you know, most zip archivers place a separate entry in the zip's central directory for each folder, before the entries for the files in that folder. Because of this, FZipFile::Open assumes that, if there is a common prefix for every file in the archive, the name of the first entry will be that prefix.
That assumption doesn't always hold. In particular, for whatever reason, Bitbucket's zip generator does [i]not[/i] generate separate zip entries for folders. Info-ZIP and 7-Zip don't emit any error messages about such archives when testing or extracting them, so this kind of zip structure seems to be generally recognized as valid. But because it isn't what FZipFile::Open expects, GZDoom doesn't load it correctly.
The attached file contains two zip archives, both containing a replacement TITLEPIC, to demonstrate the problem. “bugdemo-works.zip” has zip entries for the folders, and GZDoom loads it correctly. “bugdemo-broken.zip” has been stripped of folder entries, and while it extracts successfully with normal zip tools, GZDoom does not load it correctly.