From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Juri Linkov Newsgroups: gmane.emacs.bugs Subject: bug#10338: 23.3; Firefox includes a jar file which is not recognied as a zip file (omni.jar) Date: Thu, 22 Dec 2011 22:02:20 +0200 Organization: JURTA Message-ID: <877h1obcj7.fsf@mail.jurta.org> References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1324584372 29025 80.91.229.12 (22 Dec 2011 20:06:12 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 22 Dec 2011 20:06:12 +0000 (UTC) Cc: 10338@debbugs.gnu.org To: "Brooks\, Daniel" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Dec 22 21:06:01 2011 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Rdots-0005B5-5O for geb-bug-gnu-emacs@m.gmane.org; Thu, 22 Dec 2011 21:06:00 +0100 Original-Received: from localhost ([::1]:50694 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rdotr-0004vm-F9 for geb-bug-gnu-emacs@m.gmane.org; Thu, 22 Dec 2011 15:05:59 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:43625) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rdoto-0004vV-3g for bug-gnu-emacs@gnu.org; Thu, 22 Dec 2011 15:05:57 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Rdoti-0004jX-NU for bug-gnu-emacs@gnu.org; Thu, 22 Dec 2011 15:05:56 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:49029) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rdoti-0004jT-Kd for bug-gnu-emacs@gnu.org; Thu, 22 Dec 2011 15:05:50 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1Rdovp-0001sq-LM for bug-gnu-emacs@gnu.org; Thu, 22 Dec 2011 15:08:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Juri Linkov Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 22 Dec 2011 20:08:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 10338 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 10338-submit@debbugs.gnu.org id=B10338.13245844317184 (code B ref 10338); Thu, 22 Dec 2011 20:08:01 +0000 Original-Received: (at 10338) by debbugs.gnu.org; 22 Dec 2011 20:07:11 +0000 Original-Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Rdov1-0001rp-CB for submit@debbugs.gnu.org; Thu, 22 Dec 2011 15:07:11 -0500 Original-Received: from smarty.dreamhost.com ([208.113.175.8]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Rdoux-0001rh-Op for 10338@debbugs.gnu.org; Thu, 22 Dec 2011 15:07:09 -0500 Original-Received: from ps18281.dreamhostps.com (ps18281.dreamhost.com [69.163.218.105]) by smarty.dreamhost.com (Postfix) with ESMTP id BC50B684060; Thu, 22 Dec 2011 12:04:55 -0800 (PST) Original-Received: from localhost (ps18281.dreamhostps.com [69.163.218.105]) by ps18281.dreamhostps.com (Postfix) with ESMTP id 45270451C6F3; Thu, 22 Dec 2011 12:04:21 -0800 (PST) In-Reply-To: (Daniel Brooks's message of "Tue, 20 Dec 2011 21:51:18 -0500") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.92 (x86_64-pc-linux-gnu) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Thu, 22 Dec 2011 15:08:01 -0500 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:55117 Archived-At: > They've optimized for read performance by rearranging the sections of > the file (and the files inside the archive). As a result the magic is > slightly different and Emacs doesn't recognize the file, even though the > zip/unzip tools the user has may be well able to handle it. Here is what the author of InfoZip says about this non-standard jar format in https://bugzilla.mozilla.org/show_bug.cgi?id=605524#c11 : - Fifth, the first 10 bytes of this archive are (in hex): b8 b6 14 00 50 4b 01 02 17 0b P K 1 2 The P K 1 2 is the first Central Directory signature. The 4 bytes before that appear to be some index. Using little endian math, this ends up being 1357496, which happens to be the offset to local record #210, a .png file. Not sure if this is what it is or why this is useful. However, if everyone starts tucking their own bytes into the .zip structure without using the established procedures for doing that, I think it's asking for chaos. The standard allows leading bytes, but usually the EOCDR can point a utility to the beginning of the real archive data, but in this case the EOCDR is buried where no one can find it without scanning the archive. For testing purposes such jar files can be produced with the following utility: http://hg.mozilla.org/mozilla-central/raw-file/default/config/optimizejars.py > === modified file 'lisp/arc-mode.el' > --- lisp/arc-mode.el 2011-12-15 07:24:10 +0000 > +++ lisp/arc-mode.el 2011-12-20 22:32:35 +0000 > @@ -748,6 +748,7 @@ > ;; as an archive by other software. > (let (case-fold-search) > (cond ((looking-at "\\(PK00\\)?[P]K\003\004") 'zip) > + ((looking-at "....PK\001\002") 'zip) > ((looking-at "..-l[hz][0-9ds]-") 'lzh) > ((looking-at "....................[\334]\247\304\375") 'zoo) > ((and (looking-at "\C-z") ; signature too simple, IMHO > > I'm including a patch to 24.0.50, which I just checked out. I haven't > been using it on this machine. Thanks, your patch makes reading of non-standard jar files more permissive. There are two other places with the regexps for ZIP headers in `magic-fallback-mode-alist' and `auto-coding-regexp-alist' intended to read ZIP archives with non-standard filename extensions. Without adding "....PK\001\002" to them too, you won't able to open the "omni.ja" file (another non-standard filename extension from Mozilla). But perhaps this is not necessary - it would be too much to allow reading of files with both non-standard filename extensions and non-standard headers at the same time. More important problem is that most archivers don't understand this format, so after opening such files, extra lines are inserted into the file buffer: warning [/tmp/omni.jar]: 6552040 extra bytes at beginning or within zipfile (attempting to process anyway) error [/tmp/omni.jar]: reported length of central directory is -6552040 bytes too long (Atari STZip zipfile? J.H.Holm ZIPSPLIT 1.1 zipfile?). Compensating... It seems this problem prompted the bug#10347.