GNU bug report logs -
#3410
tar mode fails to open many valid files
Previous Next
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
Your message dated Thu, 04 Jun 2009 16:48:56 -0400
with message-id <jwvprdjlodm.fsf-monnier+emacsbugreports <at> gnu.org>
and subject line Re: bug#3410: tar mode fails to open many valid files
has caused the Emacs bug report #3410,
regarding tar mode fails to open many valid files
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact help-debbugs <at> gnu.org
immediately.)
--
3410: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3410
Emacs Bug Tracking System
Contact help-debbugs <at> gnu.org with problems
[Message part 2 (message/rfc822, inline)]
When I open a 'tar.gz' file in Emacs, it quite often fails with a
message similar to:
File mode specification error: (error
"ntWorkbookBuilder.SheetRecordCollectingListener.html\"
title=\"class in org.apache.poi.hssf.eventuserm has size
-137265917 - corrupted")
E.g. file at
http://apache.promotionalpro.com/poi/dev/bin/poi-bin-3.5-beta5-20090219.tar.gz
exhibits this error. It can be extracted without problems with 'tar
-xzf ...' at command line, so it must be a bug in Emacs' tar mode.
Maybe it is too strict or doesn't handle some extension properly.
Paul
[Message part 3 (message/rfc822, inline)]
> I.e. it works fine with
> emacs -Q ~/tmp/poi-bin-3.5-beta5-20090219.tar.gz
> but shows your problem with
> emacs -Q -f url-handler-mode; C-x C-f http://.../poi... RET
In the end you were right, and I have no idea how I managed to get the
above results. url-handler-mode makes no difference, and the 64bit
thingy makes a difference (it somehow hides the bug, so it doesn't
signal an error but instead misinterprets the middle of the tar file,
while the beginning and the end are still just fine, so my cursory check
didn't see the corruption).
I've just installed the patch below, which should fix the problem,
Stefan
--- tar-mode.el.~1.139.~ 2009-03-20 16:24:31.000000000 -0400
+++ tar-mode.el 2009-06-04 16:41:49.000000000 -0400
@@ -276,7 +276,10 @@
(setq link-p 5)) ; directory
(if (and (equal name "././@LongLink")
- (equal magic-str "ustar ")) ;OLDGNU_MAGIC.
+ ;; Supposedly @LongLink is only used for GNUTAR
+ ;; format (i.e. "ustar ") but some POSIX Tar files
+ ;; (with "ustar\0") have been seen using it as well.
+ (member magic-str '("ustar " "ustar\0")))
;; This is a GNU Tar long-file-name header.
(let* ((size (tar-parse-octal-integer
string tar-size-offset tar-time-offset))
This bug report was last modified 15 years and 328 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.