Re: bin/38066: tar doesn't dearchive correctly long symlinks

[christos%zoulas.com@localhost (Christos Zoulas)]

On Feb 20,  9:00pm, joerg%britannica.bec.de@localhost (Joerg Sonnenberger) 
wrote:
-- Subject: Re: bin/38066: tar doesn't dearchive correctly long symlinks

| The following reply was made to PR pkg/38066; it has been noted by GNATS.
| 
| From: Joerg Sonnenberger <joerg%britannica.bec.de@localhost>
| To: gnats-bugs%NetBSD.org@localhost
| Cc: 
| Subject: Re: bin/38066: tar doesn't dearchive correctly long symlinks
| Date: Wed, 20 Feb 2008 21:51:51 +0100
| 
|  On Tuesday 19 February 2008 18:50:02 Christos Zoulas wrote:
|  > This is not a bug.
|  
|  It is either a bug or a missing feature.
|  
|  > Whatever pkg_create builds:
|  > 1. Should be marked as a GNU tar archive not as a POSIX one.
|  >   i POSIX tar archives don't have ././@LongLink extensions.
|  
|  The archive created by libarchive is the pax Interchange Format as
|  defined e.g. in the Single Unix Specification version 3. The archive
|  correctly contains a pax Extended Header with the linkpath fields.
|  This overrides the value used in the following ustar header.
|
|  > 2. The extension string is "././@LongLink" not "././@LongSymLink". pax
|  >    checks for the exact name, others might check for "././@Long" or
|  >    something that is why they work.
|  
|  The value for the extension string is not used at all by GNU tar,
|  bsdtar and star.

It seems that libarchive is the only archiver that puts anything else but
././@LongLink in the extended record, and it does not need to. By not checking
the value in the extended record, we are making it impossible to have further
extensions.

christos