Opened 8 years ago

Closed 8 years ago

Last modified 8 years ago

#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 8 years ago.
sample system ZIP file packed by Archive Manager/File Roller

Download all attachments as: .zip

Change History (19)

Changed 8 years ago by mollo

Attachment: Repack.system added

sample system ZIP file packed by Archive Manager/File Roller

comment:1 Changed 8 years ago by ibboard

Milestone: WarFoundry 0.1
Priority: majorblocker

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 8 years ago by ibboard

Status: newconfirmed

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 8 years ago by ibboard

Resolution: fixed
Status: confirmedclosed

(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 8 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 8 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 8 years ago by ibboard

Resolution: fixed
Status: closedreopened

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 8 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.

comment:8 Changed 8 years ago by ibboard

In [696]:

Re #311: can't read ZIP file packed by Linux app Archive Manager/File Roller

  • Initial commit of SharpZipLib mini-port

comment:9 Changed 8 years ago by ibboard

In [698]:

Re #311: can't read ZIP file packed by Linux app Archive Manager/File Roller

Initial commit of clean SharpZipLib 0860 source. Only change is build paths.

comment:10 Changed 8 years ago by ibboard

In [699]:

Re #311: can't read ZIP file packed by Linux app Archive Manager/File Roller

comment:11 Changed 8 years ago by ibboard

In [701]:

Re #311: can't read ZIP file packed by Linux app Archive Manager/File Roller

  • Move API tests to using SharpZipLib fork

Also:

  • Convince VS2k8 that it doesn't want to keep re-updating the project

comment:12 Changed 8 years ago by ibboard

In [702]:

Re #311: can't read ZIP file packed by Linux app Archive Manager/File Roller

  • Move API to using SharpZipLib fork

Also:

  • Convince VS2k8 that it doesn't want to keep re-updating the project

comment:13 Changed 8 years ago by ibboard

In [703]:

Re #311: can't read ZIP file packed by Linux app Archive Manager/File Roller

  • Add SharpZipLib to GTK# GUI solution

comment:14 Changed 8 years ago by ibboard

In [704]:

Re #311: can't read ZIP file packed by Linux app Archive Manager/File Roller

  • Add SharpZipLib project to WinForms solution

comment:15 Changed 8 years ago by ibboard

Owner: set to ibboard
Resolution: fixed
Status: reopenedclosed

In [705]:

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

  • Add a unit test for the failure

comment:16 Changed 8 years ago by ibboard

In [706]:

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

  • Add the data files as well!

no-open-ticket

comment:17 Changed 8 years ago by mollo

WF0.1RC2b seems to have fixed the problem on my end, using File Roller over 7zip in Ubuntu 10.10.

comment:18 Changed 8 years ago by ibboard

Resolution: fixedreleased

Tag v0.1 fixes as released (finally!)

Note: See TracTickets for help on using tickets.