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.
Zip root folder detection fails if zip lacks folder entries
Moderator: GZDoom Developers
Forum rules
Please don't bump threads here if you have a problem - it will often be forgotten about if you do. Instead, make a new thread here.
Please don't bump threads here if you have a problem - it will often be forgotten about if you do. Instead, make a new thread here.
Zip root folder detection fails if zip lacks folder entries
- Attachments
-
- bugdemo.zip
- Demonstration of the problem.
- (5.12 KiB) Downloaded 132 times
- Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49067
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: Zip root folder detection fails if zip lacks folder entr
The current init code cannot detect these things, because it would have to scan the entire directory before deciding it needs to do path remapping.
The current solution was just a quick addition to the existing logic. This one will require a far more extensive rewrite, which is probably not going to happen any time soon.
The current solution was just a quick addition to the existing logic. This one will require a far more extensive rewrite, which is probably not going to happen any time soon.