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

[Eli Zaretskii <eliz@gnu.org>]

> 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.