bug#20665: 24.5.50; Error when opening zip 3.0 file in arc-mode

[Eli Zaretskii]

> Date: Tue, 26 May 2015 15:34:44 -0400
> From: Brian Caruso <briancaruso@gmail.com>
> 
> I started with emacs -Q
> The did C-x C-f and selected the file with RET
> I got this error in *Messages*:
> "Parsing archive file...
> File mode specification error: (args-out-of-range #<buffer resource_ead1.zip>
> 4294967296 4294967300)"
> I expected the arc-mode dired-like view of the file list of the zip, 
> but I got a buffer with the byte contents of the zip file.

Thanks, I fixed this in commit 1719816 for the next Emacs release.

The changes appear below, so you should be able to patch your
arc-mode.el and resolve this problem.

commit 171981622f072546aed135668e53fdeb7b012631
Author: Eli Zaretskii <eliz@gnu.org>
Date:   Wed May 27 17:35:11 2015 +0300

    Support ZIP files that use Zip64 extensions
    
    * lisp/arc-mode.el (archive-zip-summarize): Handle the new ZIP
    format of central directory offsets used by Zip64 extensions.
    (Bug#20665)

diff --git a/lisp/arc-mode.el b/lisp/arc-mode.el
index 063e4ba..5f2fc8f 100644
--- a/lisp/arc-mode.el
+++ b/lisp/arc-mode.el
@@ -1811,11 +1811,38 @@ (defalias 'archive-lzh-exe-extract 'archive-lzh-extract
 (defun archive-zip-summarize ()
   (goto-char (- (point-max) (- 22 18)))
   (search-backward-regexp "[P]K\005\006")
-  (let ((p (+ (point-min) (archive-l-e (+ (point) 16) 4)))
+  (let ((p (archive-l-e (+ (point) 16) 4))
         (maxlen 8)
        (totalsize 0)
         files
-       visual)
+       visual
+        emacs-int-has-32bits)
+    (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.
+      ;;
+      ;; First, find the Zip64 end-of-central-directory locator.
+      (search-backward "PK\006\007")
+      ;; Pay attention: the offset of Zip64 end-of-central-directory
+      ;; is a 64-bit field, so it could overflow the Emacs integer
+      ;; even on a 64-bit host, let alone 32-bit one.  But since we've
+      ;; already read the zip file into a buffer, and this is a byte
+      ;; offset into the file we've read, it must be short enough, so
+      ;; such an overflow can never happen, and we can safely read
+      ;; these 8 bytes into an Emacs integer.  Moreover, on host with
+      ;; 32-bit Emacs integer we can only read 4 bytes, since they are
+      ;; stored in little-endian byte order.
+      (setq emacs-int-has-32bits (<= most-positive-fixnum #x1fffffff))
+      (setq p (+ (point-min)
+                 (archive-l-e (+ (point) 8) (if emacs-int-has-32bits 4 8))))
+      (goto-char p)
+      ;; We should be at Zip64 end-of-central-directory record now.
+      (or (string= "PK\006\006" (buffer-substring p (+ p 4)))
+          (error "Unrecognized ZIP file format"))
+      ;; Offset to central directory:
+      (setq p (+ (point-min)
+                 (archive-l-e (+ p 48) (if emacs-int-has-32bits 4 8)))))
     (while (string= "PK\001\002" (buffer-substring p (+ p 4)))
       (let* ((creator (byte-after (+ p 5)))
             ;; (method  (archive-l-e (+ p 10) 2))