bug#258: [22.2]: visiting boost_1_35_0.tar.bz2 causes an error

bug#258: [22.2]: visiting boost_1_35_0.tar.bz2 causes an error

[Marshall, Simon]

[-- Attachment #1: Type: text/plain, Size: 5512 bytes --]

In GNU Emacs 22.2.1 (sparc-sun-solaris2.8, Motif Version 2.1.0)
 of 2008-03-28 on risksun2
Windowing system distributor `Hummingbird Ltd.', version 11.0.100015
configured using `configure
'--x-includes=/usr/openwin/include:/usr/dt/include:/usr/local/include:/u
sr/local/X11/include'
'--x-libraries=/usr/openwin/lib:/usr/dt/lib:/usr/local/lib:/usr/local/X1
1/lib' '--with-x-toolkit=motif''

This report is going to be annoying, because
http://downloads.sourceforge.net/boost/boost_1_35_0.tar.bz2?modtime=1206
795398&big_mirror=0 is a 22M file.  Sorry.  This also applies to 22.1.

If I download the file, then visiting it under emacs -Q gives me:

Debugger entered--Lisp error: (args-out-of-range -256589311 -256588799)
  buffer-substring(-256589311 -256588799)
  (tar-header-block-tokenize (buffer-substring pos (+ pos 512)))
  (setq tokens (tar-header-block-tokenize (buffer-substring pos ...)))
  (eq (quote empty-tar-block) (setq tokens (tar-header-block-tokenize
...)))
  (not (eq (quote empty-tar-block) (setq tokens ...)))
  (and (<= (+ pos 512) (point-max)) (not (eq ... ...)))
  (while (and (<= ... ...) (not ...)) (setq pos (+ pos 512))
(progress-reporter-update progress-reporter pos) (if (memq ... ...)
(setq pos ...)) (let (...) (if ... ...) (push ... result) (and ... ...
...)))
  (let* ((result ...) (pos ...) (progress-reporter ...) tokens) (while
(and ... ...) (setq pos ...) (progress-reporter-update progress-reporter
pos) (if ... ...) (let ... ... ... ...)) (make-local-variable (quote
tar-parse-info)) (setq tar-parse-info (nreverse result)) (if (eq tokens
...) (progress-reporter-done progress-reporter) (message "Warning:
premature EOF parsing tar file")))
  (let ((modified ...)) (set-buffer-multibyte nil) (let* (... ... ...
tokens) (while ... ... ... ... ...) (make-local-variable ...) (setq
tar-parse-info ...) (if ... ... ...)) (set-buffer-multibyte
default-enable-multibyte-characters) (goto-char (point-min)) (let (...)
(let ... ...) (narrow-to-region ... ...) (set ... ...) (goto-char ...)
(restore-buffer-modified-p modified)))
  tar-summarize-buffer()
  tar-mode()
  set-auto-mode-0(tar-mode nil)
  set-auto-mode()
  normal-mode(t)
  after-find-file(nil t)
  find-file-noselect-1(#<buffer boost_1_35_0.tar.bz2>
"~/ftp/boost_1_35_0.tar.bz2" nil nil "~/ftp/boost_1_35_0.tar.bz2"
(1855815 71344173))
  find-file-noselect("/homedev/marshals/ftp/boost_1_35_0.tar.bz2" nil
nil nil)
  find-file("/homedev/marshals/ftp/boost_1_35_0.tar.bz2")
  dired-advertised-find-file()
  call-interactively(dired-advertised-find-file)

The transition of pos to a negative value happens here in
tar-summarize-buffer:

          (and (null (tar-header-link-type tokens))
               (> size 0)
               (setq pos
                     (+ pos 512 (ash (ash (1- size) -9) 9)) ; this works
                                        ;(+ pos (+ size (- 512 (rem (1-
size) 512)))) ; this doesn't
                     ))

After many iterations of the enclosing loop, but before the above form,
pos=49390081 and size=230891239.  
After the above form, pos=-256589311.

The dubious value of size has come from this value of tokens in the
enclosing loop:

["boost_1_35_0/doc/html/boost/xpressive/op/insert/result_This(Cont,It,Si
ze,Value),typename disable_if" 17363925 16815366 6377612 230891239
(1040640 53316) 548 nil "" nil nil nil 0 0]

If it is any help, the value of tokens in the previous iteration of the
loop is:

[././@LongLink 0 0 0 151 (0 0) 4530 28  t  root 0 0]

If it is any help, there are no files of size 230891239 in the tar.
Solaris "tar -tf" does list many @LongLink files, whereas GNU "tar -tf"
does not.  
Solaris tar extracts a file named
"boost_1_35_0/doc/html/boost/xpressive/op/insert/result_This(Cont,It,Val
ue),typename disable_if_ mpl_", whereas GNU tar extracts it as
"boost_1_35_0/doc/html/boost/xpressive/op/insert/result_This(Cont,It,Val
ue),typename disable_if_ mpl__or__ is_integral_ UNCVREF(It)_,is_same_
UNCVREF(It),UNCVREF(Value)_ _ ___type__id1001524.html", ie, Solaris tar
truncates the file name (not file contents).  Emacs tar-mode apparently
truncates the file name further.

So it is an "unusual" tar.  There is no difference between the download
site's gzip and bzip tars.

I'm guessing that it is a valid tar though.  Emacs should be able to
parse it or fail gracefully.

Simon.



 "Misys" is the trade name for Misys plc (registered in England and Wales). Registration Number: 01360027. Registered office: Burleigh House, Chapel Oak, Salford Priors, Evesham WR11 8SP. For a list of Misys group operating companies please go to http://www.misys.com/html/about_us/group_operating_companies/. This email and any attachments have been scanned for known viruses using multiple scanners. 
 
We believe that this email and any attachments are virus free, however the recipient must take full responsibility for virus checking. This email message is intended for the named recipient only. It may be privileged and/or confidential. If you are not the named recipient of this email please notify us immediately and do not copy it or use it for any purpose, nor disclose its contents to any other person. This email does not constitute the commencement of legal relations between you and Misys plc. Please refer to the executed contract between you and the relevant member of the Misys group for the identity of the contracting party with which you are dealing. 

[-- Attachment #2: Type: text/html, Size: 12335 bytes --]

bug#258: [22.2]: visiting boost_1_35_0.tar.bz2 causes an error

[Stefan Monnier]

> This report is going to be annoying, because
> http://downloads.sourceforge.net/boost/boost_1_35_0.tar.bz2?modtime=1206
> 795398&big_mirror=0 is a 22M file.  Sorry.  This also applies to 22.1.

> If I download the file, then visiting it under emacs -Q gives me:

> Debugger entered--Lisp error: (args-out-of-range -256589311 -256588799)

The problem appears to be that the file uses a format that tar-mode.el
doesn't understand: the errors shows up with the first filename that is
longer than 100 chars.
It appears to be some GNU tar format whoe description I cannot
find anywhere.  Basically, the block that is supposed to describe the
file is replaced by a block that contains the complete filename (padded
to 512 with \0 bytes) and is followed by the actual block:

ELISP> (buffer-substring pos (+ pos 512))
"boost_1_35_0/doc/html/boost/xpressive/op/insert/result_This(Cont,It,Size,Value),typename disable_if_ is_integral_ UNCVREF(It)_ ___type__id1001471.html^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^
 @^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@"
ELISP> (buffer-substring (+ pos 512) (+ pos 1024))
"boost_1_35_0/doc/html/boost/xpressive/op/insert/result_This(Cont,It,Size,Value),typename disable_if_0000777^@0000764^@0001001^@00000012564^@10773134243^@034046^@ 0^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ustar  ^@Administrator^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@None^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
 ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@"
ELISP> 


        Stefan

bug#258: [22.2]: visiting boost_1_35_0.tar.bz2 causes an error

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Tue, 20 May 2008 14:42:05 -0400
> Cc: 258@emacsbugs.donarmstrong.com, bug-gnu-emacs@gnu.org
> 
> > This report is going to be annoying, because
> > http://downloads.sourceforge.net/boost/boost_1_35_0.tar.bz2?modtime=1206
> > 795398&big_mirror=0 is a 22M file.  Sorry.  This also applies to 22.1.
> 
> > If I download the file, then visiting it under emacs -Q gives me:
> 
> > Debugger entered--Lisp error: (args-out-of-range -256589311 -256588799)
> 
> The problem appears to be that the file uses a format that tar-mode.el
> doesn't understand: the errors shows up with the first filename that is
> longer than 100 chars.
> It appears to be some GNU tar format whoe description I cannot
> find anywhere.  Basically, the block that is supposed to describe the
> file is replaced by a block that contains the complete filename (padded
> to 512 with \0 bytes) and is followed by the actual block:

It's the ustar format used by pax.  We've bumped into this before, I
think; search the archives.  (It's strange, though: I'm quite sure I
installed a stopgap fix in the last minute before v22.1 hit the FTP
sites, so maybe I'm confused and this is another problem?)

bug#258: [22.2]: visiting boost_1_35_0.tar.bz2 causes an error

[Stefan Monnier]

>> > This report is going to be annoying, because
>> > http://downloads.sourceforge.net/boost/boost_1_35_0.tar.bz2?modtime=1206
>> > 795398&big_mirror=0 is a 22M file.  Sorry.  This also applies to 22.1.
>> 
>> > If I download the file, then visiting it under emacs -Q gives me:
>> 
>> > Debugger entered--Lisp error: (args-out-of-range -256589311 -256588799)
>> 
>> The problem appears to be that the file uses a format that tar-mode.el
>> doesn't understand: the errors shows up with the first filename that is
>> longer than 100 chars.
>> It appears to be some GNU tar format whoe description I cannot
>> find anywhere.  Basically, the block that is supposed to describe the
>> file is replaced by a block that contains the complete filename (padded
>> to 512 with \0 bytes) and is followed by the actual block:

> It's the ustar format used by pax.  We've bumped into this before, I
> think; search the archives.  (It's strange, though: I'm quite sure I
> installed a stopgap fix in the last minute before v22.1 hit the FTP
> sites, so maybe I'm confused and this is another problem?)

It doesn't look like the wiki's description of ustar.  Do you know where
I could find a description of the format in that tarball?


        Stefan

bug#258: [22.2]: visiting boost_1_35_0.tar.bz2 causes an error

[Eli Zaretskii]

> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Cc: 258@emacsbugs.donarmstrong.com, Simon.Marshall@misys.com,
>         bug-submit-list@donarmstrong.com, bug-gnu-emacs@gnu.org
> Date: Tue, 20 May 2008 21:45:14 -0400
> 
> > It's the ustar format used by pax.  We've bumped into this before, I
> > think; search the archives.  (It's strange, though: I'm quite sure I
> > installed a stopgap fix in the last minute before v22.1 hit the FTP
> > sites, so maybe I'm confused and this is another problem?)
> 
> It doesn't look like the wiki's description of ustar.  Do you know where
> I could find a description of the format in that tarball?

Not at the moment, no.  I will look.

In case you are right, and this _is_ GNU tar format, it should be
described in the GNU Tar docs, and maybe you will find more in the GNU
Tar sources.

bug#258: [22.2]: visiting boost_1_35_0.tar.bz2 causes an error

[Stefan Monnier]

>> > It's the ustar format used by pax.  We've bumped into this before, I
>> > think; search the archives.  (It's strange, though: I'm quite sure I
>> > installed a stopgap fix in the last minute before v22.1 hit the FTP
>> > sites, so maybe I'm confused and this is another problem?)
>> 
>> It doesn't look like the wiki's description of ustar.  Do you know where
>> I could find a description of the format in that tarball?

> Not at the moment, no.  I will look.

Please do, thank you.

> In case you are right, and this _is_ GNU tar format,

I don't know that it is but wikipedia seems to think that the "ustar  "
indicates it's GNU Tar format.

> it should be described in the GNU Tar docs, and maybe you will find
> more in the GNU Tar sources.

I couldn't find it in GNU Tar's Texinfo doc (it does have some
description of tar-format, as well as discussions about various formats
w.r.t how well each one is supported and how to choose among them).

Hopefully the source code has further info (well it surely does have,
in the form of actual code ;-),


        Stefan

bug#258: [22.2]: visiting boost_1_35_0.tar.bz2 causes an error

[Eli Zaretskii]

> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Cc: 258@emacsbugs.donarmstrong.com, Simon.Marshall@misys.com,
>         bug-submit-list@donarmstrong.com, bug-gnu-emacs@gnu.org
> Date: Wed, 21 May 2008 11:40:41 -0400
> 
> >> > It's the ustar format used by pax.  We've bumped into this before, I
> >> > think; search the archives.  (It's strange, though: I'm quite sure I
> >> > installed a stopgap fix in the last minute before v22.1 hit the FTP
> >> > sites, so maybe I'm confused and this is another problem?)
> >> 
> >> It doesn't look like the wiki's description of ustar.  Do you know where
> >> I could find a description of the format in that tarball?
> 
> > Not at the moment, no.  I will look.
> 
> Please do, thank you.

Sorry for a long delay.  Here's what I found:

  . `file' says that this is a POSIX Tar file.

  . Looking at the description of Tar formats in Wikipedia
    (http://en.wikipedia.org/wiki/Tar_(file_format)), this appears to
    be the POSIX Tar format created by GNU Tar: the "ustar" signature
    that is not null-terminated is followed by 0x2020 as the "version".

  . Looking at the offending tarball with Hexl, I see the telltale
    "ustar  " signature of the GNU Tar format, and all the other
    fields of the file headers look okay, just like described in the
    Wikipedia and in the other docs I could find on the net.  So I
    don't understand why you said above that this tarball doesn't look
    like wiki's description of ustar.

  . The differences between POSIX and GNU Tar formats are minor, apart
    of the way the "ustar" signature is written, as long as sparse
    files or incremental archives are not used, and tar-mode.el
    already seems to support them both, at least in the current CVS.

  . The error message I get, both with today's CVS and with Emacs
    22.1, is not the one cited at the beginning of this thread
    ("Debugger entered--Lisp error: (args-out-of-range -256589311
    -256588799)"), but this one:

       Warning: premature EOF parsing tar file

    This warning is generated because this archive includes long
    names, signaled by the special pseudo-file name "././@LongLink",
    which is where the archive listing displayed by tar-mode for this
    tarball stops.

So my conclusion is that we need to add support for "././@LongLink"
magic file names, in order to fix this problem.

(Btw, it looks like the archive which started this thread was created
on MS-Windows, since the Owner/Group are Administrator/None, and the
sizes of directories are zero.)

> > In case you are right, and this _is_ GNU tar format,
> 
> I don't know that it is but wikipedia seems to think that the "ustar  "
> indicates it's GNU Tar format.
> 
> > it should be described in the GNU Tar docs, and maybe you will find
> > more in the GNU Tar sources.
> 
> I couldn't find it in GNU Tar's Texinfo doc (it does have some
> description of tar-format, as well as discussions about various formats
> w.r.t how well each one is supported and how to choose among them).
> 
> Hopefully the source code has further info (well it surely does have,
> in the form of actual code ;-),

The place to look is in src/tar.h in the GNU Tar sources, in case
someone is interested.

As an aside, the way tar-mode formats the archive listing seems to
assume a user name is no longer than 7 characters, because for longer
names (and "Administrator" is longer), it doesn't leave any whitespace
between the file mode bits and the owner name, like so:

  drwxrwxrwxAdministrator/None          0 boost_1_35_0/
  drwxrwxrwxAdministrator/None          0 boost_1_35_0/boost/
  drwxrwxrwxAdministrator/None          0 boost_1_35_0/boost/algorithm/
  -rw-rw-rw-Administrator/None       1253 boost_1_35_0/boost/algorithm/minmax.hp\
 p
  -rw-rw-rw-Administrator/None      17435 boost_1_35_0/boost/algorithm/minmax_el\
 ement.hpp
  drwxrwxrwxAdministrator/None          0 boost_1_35_0/boost/algorithm/string/

I suggest to fix this.

bug#258: marked as done ([22.2]: visiting boost_1_35_0.tar.bz2 causes an error)

[Emacs bug Tracking System]

[-- Attachment #1: Type: text/plain, Size: 895 bytes --]


Your message dated Sun, 25 May 2008 09:49:29 -0400
with message-id <jwvve12o5on.fsf-monnier+emacsbugreports@gnu.org>
and subject line Re: bug#258: [22.2]: visiting boost_1_35_0.tar.bz2 causes an error
has caused the Emacs bug report #258,
regarding [22.2]: visiting boost_1_35_0.tar.bz2 causes an error
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 don@donarmstrong.com
immediately.)


-- 
258: http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=258
Emacs Bug Tracking System
Contact don@donarmstrong.com with problems

[-- Attachment #2: Type: message/rfc822, Size: 21017 bytes --]

[-- Attachment #2.1.1: Type: text/plain, Size: 5512 bytes --]

In GNU Emacs 22.2.1 (sparc-sun-solaris2.8, Motif Version 2.1.0)
 of 2008-03-28 on risksun2
Windowing system distributor `Hummingbird Ltd.', version 11.0.100015
configured using `configure
'--x-includes=/usr/openwin/include:/usr/dt/include:/usr/local/include:/u
sr/local/X11/include'
'--x-libraries=/usr/openwin/lib:/usr/dt/lib:/usr/local/lib:/usr/local/X1
1/lib' '--with-x-toolkit=motif''

This report is going to be annoying, because
http://downloads.sourceforge.net/boost/boost_1_35_0.tar.bz2?modtime=1206
795398&big_mirror=0 is a 22M file.  Sorry.  This also applies to 22.1.

If I download the file, then visiting it under emacs -Q gives me:

Debugger entered--Lisp error: (args-out-of-range -256589311 -256588799)
  buffer-substring(-256589311 -256588799)
  (tar-header-block-tokenize (buffer-substring pos (+ pos 512)))
  (setq tokens (tar-header-block-tokenize (buffer-substring pos ...)))
  (eq (quote empty-tar-block) (setq tokens (tar-header-block-tokenize
...)))
  (not (eq (quote empty-tar-block) (setq tokens ...)))
  (and (<= (+ pos 512) (point-max)) (not (eq ... ...)))
  (while (and (<= ... ...) (not ...)) (setq pos (+ pos 512))
(progress-reporter-update progress-reporter pos) (if (memq ... ...)
(setq pos ...)) (let (...) (if ... ...) (push ... result) (and ... ...
...)))
  (let* ((result ...) (pos ...) (progress-reporter ...) tokens) (while
(and ... ...) (setq pos ...) (progress-reporter-update progress-reporter
pos) (if ... ...) (let ... ... ... ...)) (make-local-variable (quote
tar-parse-info)) (setq tar-parse-info (nreverse result)) (if (eq tokens
...) (progress-reporter-done progress-reporter) (message "Warning:
premature EOF parsing tar file")))
  (let ((modified ...)) (set-buffer-multibyte nil) (let* (... ... ...
tokens) (while ... ... ... ... ...) (make-local-variable ...) (setq
tar-parse-info ...) (if ... ... ...)) (set-buffer-multibyte
default-enable-multibyte-characters) (goto-char (point-min)) (let (...)
(let ... ...) (narrow-to-region ... ...) (set ... ...) (goto-char ...)
(restore-buffer-modified-p modified)))
  tar-summarize-buffer()
  tar-mode()
  set-auto-mode-0(tar-mode nil)
  set-auto-mode()
  normal-mode(t)
  after-find-file(nil t)
  find-file-noselect-1(#<buffer boost_1_35_0.tar.bz2>
"~/ftp/boost_1_35_0.tar.bz2" nil nil "~/ftp/boost_1_35_0.tar.bz2"
(1855815 71344173))
  find-file-noselect("/homedev/marshals/ftp/boost_1_35_0.tar.bz2" nil
nil nil)
  find-file("/homedev/marshals/ftp/boost_1_35_0.tar.bz2")
  dired-advertised-find-file()
  call-interactively(dired-advertised-find-file)

The transition of pos to a negative value happens here in
tar-summarize-buffer:

          (and (null (tar-header-link-type tokens))
               (> size 0)
               (setq pos
                     (+ pos 512 (ash (ash (1- size) -9) 9)) ; this works
                                        ;(+ pos (+ size (- 512 (rem (1-
size) 512)))) ; this doesn't
                     ))

After many iterations of the enclosing loop, but before the above form,
pos=49390081 and size=230891239.  
After the above form, pos=-256589311.

The dubious value of size has come from this value of tokens in the
enclosing loop:

["boost_1_35_0/doc/html/boost/xpressive/op/insert/result_This(Cont,It,Si
ze,Value),typename disable_if" 17363925 16815366 6377612 230891239
(1040640 53316) 548 nil "" nil nil nil 0 0]

If it is any help, the value of tokens in the previous iteration of the
loop is:

[././@LongLink 0 0 0 151 (0 0) 4530 28  t  root 0 0]

If it is any help, there are no files of size 230891239 in the tar.
Solaris "tar -tf" does list many @LongLink files, whereas GNU "tar -tf"
does not.  
Solaris tar extracts a file named
"boost_1_35_0/doc/html/boost/xpressive/op/insert/result_This(Cont,It,Val
ue),typename disable_if_ mpl_", whereas GNU tar extracts it as
"boost_1_35_0/doc/html/boost/xpressive/op/insert/result_This(Cont,It,Val
ue),typename disable_if_ mpl__or__ is_integral_ UNCVREF(It)_,is_same_
UNCVREF(It),UNCVREF(Value)_ _ ___type__id1001524.html", ie, Solaris tar
truncates the file name (not file contents).  Emacs tar-mode apparently
truncates the file name further.

So it is an "unusual" tar.  There is no difference between the download
site's gzip and bzip tars.

I'm guessing that it is a valid tar though.  Emacs should be able to
parse it or fail gracefully.

Simon.



 "Misys" is the trade name for Misys plc (registered in England and Wales). Registration Number: 01360027. Registered office: Burleigh House, Chapel Oak, Salford Priors, Evesham WR11 8SP. For a list of Misys group operating companies please go to http://www.misys.com/html/about_us/group_operating_companies/. This email and any attachments have been scanned for known viruses using multiple scanners. 
 
We believe that this email and any attachments are virus free, however the recipient must take full responsibility for virus checking. This email message is intended for the named recipient only. It may be privileged and/or confidential. If you are not the named recipient of this email please notify us immediately and do not copy it or use it for any purpose, nor disclose its contents to any other person. This email does not constitute the commencement of legal relations between you and Misys plc. Please refer to the executed contract between you and the relevant member of the Misys group for the identity of the contracting party with which you are dealing. 

[-- Attachment #2.1.2: Type: text/html, Size: 12335 bytes --]

[-- Attachment #3: Type: message/rfc822, Size: 2706 bytes --]

From: Stefan Monnier <monnier@iro.umontreal.ca>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 258-done@emacsbugs.donarmstrong.com
Subject: Re: bug#258: [22.2]: visiting boost_1_35_0.tar.bz2 causes an error
Date: Sun, 25 May 2008 09:49:29 -0400
Message-ID: <jwvve12o5on.fsf-monnier+emacsbugreports@gnu.org>

I've just installed the patch belwo into the 22 branch.
It seems to fix this problem,


        Stefan


--- tar-mode.el.~1.108.2.5.~	2008-01-31 22:09:37.000000000 -0500
+++ tar-mode.el	2008-05-25 09:47:33.000000000 -0400
@@ -421,6 +421,16 @@
                                  (tar-header-block-tokenize
                                   (buffer-substring pos (+ pos 512)))))))
         (setq pos (+ pos 512))
+        (when (equal (tar-header-name tokens) "././@LongLink")
+          ;; This is a GNU Tar long-file-name header.
+          (let* ((size (tar-header-size tokens))
+                 ;; -1 so as to strip the terminating 0 byte.
+                 (name (buffer-substring pos (+ pos size -1))))
+            (setq pos (+ pos (ash (ash (+ 511 size) -9) 9)))
+            (setq tokens (tar-header-block-tokenize
+                          (buffer-substring pos (+ pos 512))))
+            (tar-setf (tar-header-name tokens) name)
+            (setq pos (+ pos 512))))
         (progress-reporter-update progress-reporter pos)
         (if (memq (tar-header-link-type tokens) '(20 55))
             ;; Foo.  There's an extra empty block after these.