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

Previous Next

Full log

View this message in rfc822 format

From: Stephen Berman <stephen.berman <at> gmx.net>
To: Andreas Schwab <schwab <at> linux-m68k.org>
Cc: 43597 <at> debbugs.gnu.org
Subject: bug#43597: 28.0.50; arc-mode.el fails to display a ZIP file
Date: Fri, 25 Sep 2020 00:20:18 +0200

On Thu, 24 Sep 2020 23:58:51 +0200 Stephen Berman <stephen.berman <at> gmx.net> wrote:

> On Thu, 24 Sep 2020 22:40:15 +0200 Stephen Berman <stephen.berman <at> gmx.net> wrote:
>
>> 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.
>
> I've confirmed that changing the when-clause condition to (= p
> 4294967295) (that's octal 37777777777, hex ffffffff) makes the body get
> executed and the contents of the problematic ZIP file are correctly
> displayed in archive-mode.  Is that the correct fix?

No, it's not, at least not without additional changes.  I looked at the
display in archive-mode too quickly before; looking again, I see that
each file in the archive is shown as having size 4294967295 and the
total size shown is correspondingly wrong.

Steve Berman

Previous Next

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