Account Options

  1. Sign in
The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Google Groups Home
« Groups Home
Message from discussion Issue 257 in libarchive: libarchive fails to process some sfx zip files

Received: by 10.101.152.19 with SMTP id e19mr6437426ano.9.1335211858722;
        Mon, 23 Apr 2012 13:10:58 -0700 (PDT)
X-BeenThere: libarchive-discuss@googlegroups.com
Received: by 10.236.114.50 with SMTP id b38ls9794381yhh.1.gmail; Mon, 23 Apr
 2012 13:10:58 -0700 (PDT)
Received: by 10.101.151.23 with SMTP id d23mr6384147ano.11.1335211858436;
        Mon, 23 Apr 2012 13:10:58 -0700 (PDT)
Received: by 10.101.151.23 with SMTP id d23mr6384146ano.11.1335211858417;
        Mon, 23 Apr 2012 13:10:58 -0700 (PDT)
Return-Path: <3UreVTwoOAJkEB43K5ABO79HH9E75H67....@codesite.bounces.google.com>
Received: from mail-gy0-f203.google.com (mail-gy0-f203.google.com [209.85.160.203])
        by gmr-mx.google.com with ESMTPS id y36si556661yhg.2.2012.04.23.13.10.58
        (version=TLSv1/SSLv3 cipher=OTHER);
        Mon, 23 Apr 2012 13:10:58 -0700 (PDT)
Received-SPF: pass (google.com: domain of 3UreVTwoOAJkEB43K5ABO79HH9E75H67....@codesite.bounces.google.com designates 209.85.160.203 as permitted sender) client-ip=209.85.160.203;
Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of 3UreVTwoOAJkEB43K5ABO79HH9E75H67....@codesite.bounces.google.com designates 209.85.160.203 as permitted sender) smtp.mail=3UreVTwoOAJkEB43K5ABO79HH9E75H67....@codesite.bounces.google.com
Received: by ghbg20 with SMTP id g20so1756451ghb.4
        for <libarchive-discuss@googlegroups.com>; Mon, 23 Apr 2012 13:10:58 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.224.97.134 with SMTP id l6mr6659616qan.6.1335211858327; Mon,
 23 Apr 2012 13:10:58 -0700 (PDT)
Reply-To: codesite-nore...@google.com
X-Generated-By: Google Code
X-GoogleCode-Project: libarchive
X-GoogleCode-Issue-Id: 257
References: <1-15611153164962775752-16041724544093949932-libarchive=googlecode.com@googlecode.com>
 <0-15611153164962775752-16041724544093949932-libarchive=googlecode.com@googlecode.com>
In-Reply-To: <1-15611153164962775752-16041724544093949932-libarchive=googlecode.com@googlecode.com>
Message-ID: <2-15611153164962775752-16041724544093949932-libarchive=googlecode.com@googlecode.com>
Date: Mon, 23 Apr 2012 20:10:58 +0000
Subject: Re: Issue 257 in libarchive: libarchive fails to process some sfx zip files
From: libarch...@googlecode.com
To: libarchive-discuss@googlegroups.com
Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes


Comment #2 on issue 257 by alexkozl...@gmail.com: libarchive fails to  
process some sfx zip files
http://code.google.com/p/libarchive/issues/detail?id=257

It seems that sfx archives like this is normal for infozip. From  
unzipsfx.txt (unzip 6.0):
Regular unzip may still be used to extract the  embedded  archive  as   
with  any normal zipfile, although it will generate a warning about extra  
bytes at the  beginning  of  the  zipfile. Despite this, however, the  
self-extracting archive is technically not a valid ZIP archive, and PKUNZIP  
may be unable to test or extract it. This limitation is due to the  
simplistic manner in which the archive is created; the internal directory  
structure is not updated to reflect the extra bytes prepended to the  
original zipfile.

I can try and produce the patch for libarchive that implements this logic.