Context Navigation

← Previous Ticket
Next Ticket →

#311 closed defect (released)

can't read ZIP file packed by Linux app Archive Manager/File Roller

Reported by:	mollo	Owned by:	ibboard
Priority:	blocker	Milestone:	WarFoundry 0.1
Component:	WarFoundry-API	Version:	WarFoundry 0.1RC2
Keywords:	ZIP	Cc:
Blocked By:		Blocking:

Description

WF tries to read file, but reports a ZIP version related error in the log file

WF log file and ZIP packing log included in attached system file.

Attachments (1)

Repack.system (1.3 KB) - added by mollo 9 years ago.: sample system ZIP file packed by Archive Manager/File Roller

Download all attachments as: .zip

Change History (19)

Changed 9 years ago by mollo

Attachment:	Repack.system added

sample system ZIP file packed by Archive Manager/File Roller

comment:1 Changed 9 years ago by ibboard

Milestone:	→ WarFoundry 0.1
Priority:	major → blocker

From the look of that log file then you've used 7zip as the back-end to File Roller. IIRC the files were originally made using File Roller and subsequently modified in Windows, and they all worked. I don't have 7zip installed on my machines in general (I almost never encounter a file that requires it, and File Roller uses other backends for zip, gzip and bzip) so I'll see how it behaves.

Can you do a test for me? Could you try removing the 7zip package and seeing if File Roller generates a valid Zip file then?

Priority bumped, because we shouldn't lock people out based on which file they use (even if it might be an underlying issue with either 7zip or SharpZipLib).

comment:2 Changed 9 years ago by ibboard

Status:	new → confirmed

Actually, reading the standard (Section J - Explanation of fields) then 7zip is probably correct and SharpZipLib is wrong. 788 is the hex "14 03" as a little-endian Int16. The first byte is supposed to be the version of the Zip standard (0x14 = 20) and the second byte is the line record format (0x03 = Unix). 7zip might not need to declare Unix, but doing so is perfectly valid. Removing p7zip and using File Roller then results in "14 00", which SharpZipLib handles fine.

comment:3 Changed 9 years ago by ibboard

Resolution:	→ fixed
Status:	confirmed → closed

(In r694) Fixes #311: can't read ZIP file packed by Linux app Archive Manager/File Roller

Update SharpZipLib to 0860 so that it doesn't mis-handle line record format values

comment:4 Changed 9 years ago by ibboard

I won't get a chance to release this until Monday at the earliest, so please either update to the latest version of the API from Subversion or download the file and overwrite the existing version (I've just tried and it seems to work).

comment:5 Changed 9 years ago by mollo

no luck on my end, after replacing the SharpZipLib from rev 694 you linked, still receiving error below in the log:

WARN [00:10:23]: FrmMain.FileLoadingFinished() - Line: 0 - Failed to load /media/dns/WarFoundry-WinForms-v0.1-RC2/data/Repack.system: Version required to extract this entry not supported (788)

comment:6 Changed 9 years ago by ibboard

Resolution:	fixed
Status:	closed → reopened

Drat, it looks like it works if I update the .systemx to a new ID (which causes File Roller to re-pack that bit of data, but which leaves the headers appearing the same) but not with the very original file. I'll have to delay a little longer while I investigate what we can do and what the differences are.

comment:7 Changed 9 years ago by ibboard

I've just downloaded VBinDiff (a visual binary file differ - so it highlights the differences rather than just saying "this line differs") and it looks like I was just reading the headers for the log file in the Zip. Since the lot file wasn't recompressed when I edited IDs then it looked like the file wasn't changed, but each file has its own header and the header for the systemx file was changed. I'll see what can be done and what "Unix" format really means.