GNU bug report logs - #43597
28.0.50; arc-mode.el fails to display a ZIP file

Previous Next

Package: emacs;

Reported by: Stephen Berman <stephen.berman <at> gmx.net>

Date: Thu, 24 Sep 2020 20:04:02 UTC

Severity: normal

Found in version 28.0.50

Done: Eli Zaretskii <eliz <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


Message #11 received at 43597 <at> debbugs.gnu.org (full text, mbox):

From: Stephen Berman <stephen.berman <at> gmx.net>
To: Andreas Schwab <schwab <at> linux-m68k.org>
Cc: 43597 <at> debbugs.gnu.org
Subject: Re: bug#43597: 28.0.50; arc-mode.el fails to display a ZIP file
Date: Thu, 24 Sep 2020 22:40:15 +0200
On Thu, 24 Sep 2020 22:25:23 +0200 Andreas Schwab <schwab <at> linux-m68k.org> wrote:

> On Sep 24 2020, Stephen Berman wrote:
>
>> In case it helps, here is the final byte sequence in the file (I've
>> replace the control characters and raw bytes by ASCII representations):
>>
>> PK^E^F\377\377\377\377%^@%^@\377\377\377\377\377\377\377\377^@^@
>
> That means the archive is in ZIP64 format.  See
> <https://pkware.cachefly.net/webdocs/casestudies/APPNOTE.TXT>.  The real
> values are contained in the zip64 end of central directory record, which
> has "PK\6\6" as the signature.

Thanks.  But then it seems that arc-mode.el doesn't handle this format
correctly: archive-zip-summarize has this code:

  (let ((p (archive-l-e (+ (point) 16) 4))
        files)
    (when (= p -1)
      ;; If the offset of end-of-central-directory is -1, this is a
      ;; Zip64 extended ZIP file format, and we need to glean the info
      ;; from Zip64 records instead.

But the first value returned by archive-l-e for this file is 255, not
-1, and on each iteration the value increases, so the ZIP64 code in the
body of the when-clause is never executed.

Steve Berman




This bug report was last modified 4 years and 298 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.