archive/tar and @LongLink
Mike Rosset
I've created a generic tar ball extractor. however I ran into a
problem with with tar and @LongLink.
I was wonder if archive/tar supports Long Links or am I just going
about dealing with them wrong?
I can post a snippet or something if need be. but so far the only
tarball I can find with Long Links is
http://mirrors.kernel.org/gnu/gcc/gcc-4.6.0/gcc-4.6.0.tar.bz2
so makes testing hard, and I'm not 100% sure what a long link is
compared to say symlink or link.
Regards,
Mike
David Symonds
it's most likely that archive/tar doesn't support them.
Dave.
Mike Ramirez
I believe it refers to really long symlinks. like:
/home/nino/prog/ports/ports/scrollkeeper/work/fake-i386/usr/local/share/ \
gnome/scrollkeeper/Templates/bg_BG -> /home/nino/prog/ports/ports/scrollkeeper
\
/work/fake-i386/usr/local/share/gnome/scrollkeeper/Templates/bg
I'm not sure of the limits, but this one comes from this thread[1] (might be
unrelated to tar, just a reference to a long link breaking openbsds
pkg_create).
Long Links is a GNU extension to tar and not POSIX, if I'm interpretting this
paragraph correctly.
`In a few years, when GNU tar will produce POSIX headers by default, --posix
will have a strong meaning and will disallow GNU extensions. But in the
meantime, for a long while, --posix in GNU tar will not disallow GNU
extensions like --label=archive-label (-V archive-label), --multi-volume (-M),
--sparse (-S), or very long file or link names. However, --posix with GNU
extensions will use POSIX headers with reserved-for-users extensions to
headers, and I will be curious to know how well or bad POSIX tars will react
to these.`[2] (scroll way down).
Ultimately I don't think this is a worry.
Mike
[1] http://www.monkey.org/openbsd/archive/ports/0106/msg00131.html
[2] http://www.delorie.com/gnu/docs/tar/tar_114.html
--
The difference between a lawyer and a rooster is that
the rooster gets up in the morning and clucks defiance.
Mike Rosset
> paragraph correctly.
I think this is the case.
> Ultimately I don't think this is a worry.
This part I'm not to sure about, since I'm sure someone else will run
into this same problem. I could just just fork calls to bsdtar or tar,
but that wont help the next person that needs to handle long links.
Or are you suggesting long links are just very rare?
Regards,
Mike
Mike Rosset
> symlinks, using absolute paths for them on a deeply nested directory structure
> or with really long names. In the majority of cases long links could be
> avoided or fixed by the person using them.
>
> Mike
>
> --
> In order to discover who you are, first learn who everybody else is;
> you're what's left.
>
Ah ok that make sense. and why possible I've only run across it with
the gcc tarball.
Ok so seems this is a rare case then. and I'll just have to figure out
a better way to deal with that tarball.
Regards,
Mike
Ian Lance Taylor
> I implemented archive/tar, and I don't know what a "long link" is, so
> it's most likely that archive/tar doesn't support them.
As you know, the pre-pax tar formats had limits on the name and linkname
fields in the tar header. GNU tar avoided these limits by writing out a
dummy file before the file which needed the long name or linkname. The
dummy file is named ././@LongLink. The type field is 'L' for a long
name or 'K' for a long link name. The contents of the dummy file are
the value to use for the appropriate field in the following non-longlink
header.
I don't think there is any reason to generate these files today--the pax
format should presumably be generated instead--but these tar files are
still found in the wild. GNU tar will generate them if you use the
--format=gnu option.
Ian
Mike Rosset
> David Symonds <dsym...@golang.org> writes:
>
>> I implemented archive/tar, and I don't know what a "long link" is, so
>> it's most likely that archive/tar doesn't support them.
>
> As you know, the pre-pax tar formats had limits on the name and linkname
> fields in the tar header. GNU tar avoided these limits by writing out a
> dummy file before the file which needed the long name or linkname. The
> dummy file is named ././@LongLink. The type field is 'L' for a long
> name or 'K' for a long link name. The contents of the dummy file are
> the value to use for the appropriate field in the following non-longlink
> header.
After reading the bsd tar page and gnu tar page. I get the impression
that I can use the file data to recreate the links where need. Not
sure you i'll have to look into.
> I don't think there is any reason to generate these files today--the pax
> format should presumably be generated instead--but these tar files are
> still found in the wild. GNU tar will generate them if you use the
> --format=gnu option.
As for why they used this with the gcc tarball, I'm going to assume
they did it for a good reason? Or might this be something they would
like to know about?
Regards,
Mike
Mike Rosset
>>On Wed, Mar 30, 2011 at 10:03 PM, Ian Lance Taylor <ia...@google.com> wrote:
>> David Symonds <dsym...@golang.org> writes:
>>
>>> I implemented archive/tar, and I don't know what a "long link" is, so
>>> it's most likely that archive/tar doesn't support them.
>>
>> As you know, the pre-pax tar formats had limits on the name and linkname
>> fields in the tar header. GNU tar avoided these limits by writing out a
>> dummy file before the file which needed the long name or linkname. The
>> dummy file is named ././@LongLink. The type field is 'L' for a long
>> name or 'K' for a long link name. The contents of the dummy file are
>> the value to use for the appropriate field in the following non-longlink
>> header.
>
> After reading the bsd tar page and gnu tar page. I get the impression
> that I can use the file data to recreate the links where need. Not
> sure you i'll have to look into.
Ian Lance Taylor
>> I don't think there is any reason to generate these files today--the pax
>> format should presumably be generated instead--but these tar files are
>> still found in the wild. GNU tar will generate them if you use the
>> --format=gnu option.
>
> As for why they used this with the gcc tarball, I'm going to assume
> they did it for a good reason? Or might this be something they would
> like to know about?
Looking at the GNU tar sources it may be that --format=gnu is the
default, at least for some configurations.
I brought it up on the g...@gcc.gnu.org mailing list.
Ian
Mike Rosset
Ok thanks Ian, mean time I think I can still handle ././@LongLink with
if string(hdr.Typeflag) == "L"
And then reading the tr reader into a buffer. I can gain the link
details from there . still working on that.
Ok I want drag the thread on. I'm pretty confident I get sort it out from here.
Great job on archive/tar and bzip2 and friends. been fun hacking away with them.
Regards,
Mike
