Civilian Population wont install #2285
Comments
|
Looks like another ZIP format problem. 1.24.0-PRE-2 output: |
|
It's possible to get slightly more info out of SharpZipLib, but the interface isn't pretty... That's thrown here: So it thinks some version associated with that ZIP entry doesn't match some other version associated with that ZIP entry. Unfortunately neither of the mismatching values are captured in the exception, so we would have to do even more reverse engineering to progress on this... |
|
Idea: replace .tmp with .zip in /tmp/tmp3d949642.tmp |
No effect. |
|
OK, updates on my education in the world of ZIP file formatting... For each file contained in a ZIP file, several pieces of information are stored, and "version to extract" is one of them. This roughly tells you the version of the MS-DOS PKZip utility that you need to extract that specific file from the archive (times 10, because the real world value 2.0 becomes 20 in the file). For reference, PKZip 2.04c was released in 1993, and the "4c" part was to distinguish it from fake malware trojans that were released earlier. However, this metadata information is stored twice, once in a "local file header" near the compressed file data, and once at the end of the ZIP in an entry in the "central directory": Some nicer illustrations showing the duplicate field. When we call The Where does this leave us? Well, if it turns out that these values do in fact disagree, then SharpZipLib is technically right: it's not a valid ZIP file; a client from 1992 would not be able to make a reliable determination of whether it could decompress this file, since there would be one version in one place and a different version in another place, and it wouldn't know which was correct. However, for us today, the "version to extract" field is essentially meaningless and useless (we are not going to suddenly revert back to code from 1992 such that PKZip 2.0 is relevant). So the file is still usable, meaning we have no problems getting the data out if we're willing to ignore SharpZipLib's file validity check. SharpZipLib provides no way to work around this. There are no input flags that would allow us to skip this check or any machine readable output values that we could use to ignore this specific problem; all we get is a yes or no. The SharpZipLib project is currently unmaintained, so any pull requests to improve this would probably not be merged, and we would have to wait for a new release anyway. The most we could do in theory would be to stop calling |
|
Confirmed. The So the version in the LFH is 0xa, which is 10, which means PKZip 1.0, which disagrees with the 20 / 2.0 in the central directory. |
|
Oke can you build with this fork[1] of ZipFile? |
|
There are no relevant changes in that fork. All they changed in ZipFile and ZipEntry is the indentation character. EDIT: And it looks like they haven't done any of their own releases yet, either, let alone getting them onto NuGet. |
|
@rleroy reports that this archive was generated with the Java-based Maven Assembly Plugin, which uses Plexus Archiver, which uses Commons Compress (an apache.org project). In the course of auditing CC, I've found that just these few bytes themselves are invalid: The first "08 08" sequence is a "general purpose bit flag" not relevant to us here, but the "08" after that specifies that the compression method is DEFLATED, which requires PKZip 2.0. So even without any further context we can see there's a problem with this ZIP: it's telling PKZip 1.0 that it can extract a file that it can't extract. CC's code to set the version checks the method, and it's used by both the central file header (correct) and the local file header (incorrect): ... so something weird is going on
EDIT: Not possible, the 08 highlighted above would be 00 if method was STORED at LFH generation. |
|
Created upstream report: Hopefully someone on that project can figure out what's going on. In the meantime, I don't think we can make a CKAN code change to improve the situation. |
|
OK, my Commons Compress bug got closed as a duplicate, fixed in version 1.15. Checking my package manager, I have 1.13 installed (on Ubuntu), so that story makes sense. I'll relay this to the forum thread... |
|
There are new releases of this mod that don't have this problem. |
Background
CKAN Version:
v1.22.6+e8e10ae2e98e
KSP Version:
1.3.1
Operating System:
Ubuntu 17.10 64bit
Have you made any manual changes to your GameData folder (i.e., not via CKAN)?
Clean install
Problem
Civilian Population wont install.
What steps did you take in CKAN?
mono ckan.exe install CivilianPopulation
What did you expect to happen?
Install Civilian Population.
What happened instead?
Crash report
CKAN error codes (if applicable):
wget output:
The text was updated successfully, but these errors were encountered: