NetBSD Problem Report #38066

From root@pr1.girsa.ro  Tue Feb 19 16:31:21 2008
Return-Path: <root@pr1.girsa.ro>
Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11])
	by narn.NetBSD.org (Postfix) with ESMTP id B688963B293
	for <gnats-bugs@gnats.NetBSD.org>; Tue, 19 Feb 2008 16:31:20 +0000 (UTC)
Message-Id: <20080219153100.AA52AD5F0D@pr1.girsa.ro>
Date: Tue, 19 Feb 2008 17:31:00 +0200 (EET)
From: kefren@ngnetworks.ro
Reply-To: kefren@ngnetworks.ro
To: gnats-bugs@gnats.NetBSD.org
Subject: tar doesn't dearchive correctly long symlinks
X-Send-Pr-Version: 3.95

>Number:         38066
>Category:       pkg
>Synopsis:       tar doesn't dearchive correctly long symlinks
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    joerg
>State:          analyzed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Feb 19 16:35:00 +0000 2008
>Closed-Date:    
>Last-Modified:  Sun Aug 02 02:00:30 +0000 2009
>Originator:     Mihai Chelaru
>Release:        NetBSD 4.0_RC1
>Organization:

>Environment:


System: NetBSD pr1.girsa.ro 4.0_RC1 NetBSD 4.0_RC1 (Kefren.MPACPI) #2: Sun Sep 2 19:50:00 EEST 2007 root@pr1.girsa.ro:/usr/src-40/sys/arch/i386/compile/obj/Kefren.MPACPI i386
Architecture: i386
Machine: i386
>Description:

	tar/pax doesn't dearchive correctly long symlinks from a pax_restricted archive type
	like the ones pkg_create builds. gtar and bsdtar work correctly.

pr1# tar vft mono-1.2.6.tar | grep 1.0/System.Runtime.Serialization.Formatters.Soap.dll 
lrwxr-xr-x  1 root     wheel          0 Feb 19 16:55 lib/mono/1.0/System.Runtime.Serialization.Formatters.Soap.dll -> ././@LongSymLink
pr1# gtar vft mono-1.2.6.tar | grep 1.0/System.Runtime.Serialization.Formatters.Soap.dll
lrwxr-xr-x root/wheel        0 2008-02-19 16:55:44 lib/mono/1.0/System.Runtime.Serialization.Formatters.Soap.dll -> ../gac/System.Runtime.Serialization.Formatters.Soap/1.0.5000.0__b03f5f7f11d50a3a/System.Runtime.Serialization.Formatters.Soap.dll
pr1# bsdtar vft mono-1.2.6.tar | grep 1.0/System.Runtime.Serialization.Formatters.Soap.dll
lrwxr-xr-x  1 root   wheel       0 Feb 19 16:55 lib/mono/1.0/System.Runtime.Serialization.Formatters.Soap.dll -> ../gac/System.Runtime.Serialization.Formatters.Soap/1.0.5000.0__b03f5f7f11d50a3a/System.Runtime.Serialization.Formatters.Soap.dll 
pr1# file mono-1.2.6.tar                                                                                         
mono-1.2.6.tar: POSIX tar archive
>How-To-Repeat:

>Fix:


>Release-Note:

>Audit-Trail:
From: christos@zoulas.com (Christos Zoulas)
To: gnats-bugs@NetBSD.org, gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Cc: 
Subject: Re: bin/38066: tar doesn't dearchive correctly long symlinks
Date: Tue, 19 Feb 2008 11:47:05 -0500

 On Feb 19,  4:35pm, kefren@ngnetworks.ro (kefren@ngnetworks.ro) wrote:
 -- Subject: bin/38066: tar doesn't dearchive correctly long symlinks

 | >Number:         38066
 | >Category:       bin
 | >Synopsis:       tar doesn't dearchive correctly long symlinks
 | >Confidential:   no
 | >Severity:       non-critical
 | >Priority:       medium
 | >Responsible:    bin-bug-people
 | >State:          open
 | >Class:          sw-bug
 | >Submitter-Id:   net
 | >Arrival-Date:   Tue Feb 19 16:35:00 +0000 2008
 | >Originator:     Mihai Chelaru
 | >Release:        NetBSD 4.0_RC1
 | >Organization:
 | 	
 | >Environment:
 | 	
 | 	
 | System: NetBSD pr1.girsa.ro 4.0_RC1 NetBSD 4.0_RC1 (Kefren.MPACPI) #2: Sun Sep 2 19:50:00 EEST 2007 root@pr1.girsa.ro:/usr/src-40/sys/arch/i386/compile/obj/Kefren.MPACPI i386
 | Architecture: i386
 | Machine: i386
 | >Description:
 | 	
 | 	tar/pax doesn't dearchive correctly long symlinks from a pax_restricted archive type
 | 	like the ones pkg_create builds. gtar and bsdtar work correctly.
 | 
 | pr1# tar vft mono-1.2.6.tar | grep 1.0/System.Runtime.Serialization.Formatters.Soap.dll 
 | lrwxr-xr-x  1 root     wheel          0 Feb 19 16:55 lib/mono/1.0/System.Runtime.Serialization.Formatters.Soap.dll -> ././@LongSymLink
 | pr1# gtar vft mono-1.2.6.tar | grep 1.0/System.Runtime.Serialization.Formatters.Soap.dll
 | lrwxr-xr-x root/wheel        0 2008-02-19 16:55:44 lib/mono/1.0/System.Runtime.Serialization.Formatters.Soap.dll -> ../gac/System.Runtime.Serialization.Formatters.Soap/1.0.5000.0__b03f5f7f11d50a3a/System.Runtime.Serialization.Formatters.Soap.dll
 | pr1# bsdtar vft mono-1.2.6.tar | grep 1.0/System.Runtime.Serialization.Formatters.Soap.dll
 | lrwxr-xr-x  1 root   wheel       0 Feb 19 16:55 lib/mono/1.0/System.Runtime.Serialization.Formatters.Soap.dll -> ../gac/System.Runtime.Serialization.Formatters.Soap/1.0.5000.0__b03f5f7f11d50a3a/System.Runtime.Serialization.Formatters.Soap.dll 
 | pr1# file mono-1.2.6.tar                                                                                         
 | mono-1.2.6.tar: POSIX tar archive

 This is not a bug. Whatever pkg_create builds:
 1. Should be marked as a GNU tar archive not as a POSIX one.
    POSIX tar archives don't have ././@LongLink extensions.
 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.

 christos

Responsible-Changed-From-To: bin-bug-people->joerg
Responsible-Changed-By: wiz@narn.netbsd.org
Responsible-Changed-When: Wed, 20 Feb 2008 10:16:25 +0000
Responsible-Changed-Why:
Looks like a pkg_add (or libarchive) bug.


From: Mihai Chelaru <kefren@ngnetworks.ro>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: bin/38066: tar doesn't dearchive correctly long symlinks
Date: Wed, 20 Feb 2008 12:22:38 +0200

 On Tuesday 19 February 2008 18:50:02 Christos Zoulas wrote:
 > =A0This is not a bug. Whatever pkg_create builds:
 > =A01. Should be marked as a GNU tar archive not as a POSIX one.
 > =A0 =A0 POSIX tar archives don't have ././@LongLink extensions.
 > =A02. The extension string is "././@LongLink" not "././@LongSymLink". pax
 > =A0 =A0 checks for the exact name, others might check for "././@Long" or
 > something that is why they work.

 In this case, it looks like an libarchive bug that uses LongSymLink and=20
 LongHardLink. Also archive_write(3) man page states that:

             "The pax interchange format is a backwards-
              compatible tar format that adds key/value attributes to each
              entry and supports arbitrary filenames, linknames, uids, sizes,
              etc. ``Restricted pax interchange format'' is the library
              default; this is the same as pax format, but suppresses the pax
              extended header for most normal files.  In most cases, this wi=
 ll
              result in ordinary ustar archives."

From: Joerg Sonnenberger <joerg@britannica.bec.de>
To: gnats-bugs@NetBSD.org
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.

 Joerg

From: christos@zoulas.com (Christos Zoulas)
To: gnats-bugs@NetBSD.org, joerg@NetBSD.org, gnats-admin@netbsd.org, 
	pkgsrc-bugs@netbsd.org, kefren@ngnetworks.ro
Cc: 
Subject: Re: bin/38066: tar doesn't dearchive correctly long symlinks
Date: Thu, 21 Feb 2008 09:01:27 -0500

 On Feb 20,  9:00pm, joerg@britannica.bec.de (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>
 | To: gnats-bugs@NetBSD.org
 | 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

From: Joerg Sonnenberger <joerg@britannica.bec.de>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: bin/38066: tar doesn't dearchive correctly long symlinks
Date: Thu, 21 Feb 2008 17:19:23 +0100

 On Thu, Feb 21, 2008 at 02:05:03PM +0000, Christos Zoulas wrote:
 >  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.

 star also has ././@LongName. Let me repeat -- this flags all have
 correct POSIX compliant fields. Those should be used and not magic
 matching on the name.

 Joerg

State-Changed-From-To: open->feedback
State-Changed-By: joerg@NetBSD.org
State-Changed-When: Thu, 08 May 2008 14:58:47 +0000
State-Changed-Why:
Does it work with the pkg_install-renovation branch of
pkg_install? E.g. cvs up -r pkg_install-renovation in
pkgtools/pkg_install?


From: Mihai Chelaru <kefren@ngnetworks.ro>
To: gnats-bugs@netbsd.org
Cc: joerg@netbsd.org,
 pkgsrc-bugs@netbsd.org,
 gnats-admin@netbsd.org
Subject: Re: pkg/38066 (tar doesn't dearchive correctly long symlinks)
Date: Tue, 20 May 2008 15:11:25 +0300

 Problem is still alive with pkgtoos/pkg_install in pkg_install-renovation 
 branch from today.

From: Joerg Sonnenberger <joerg@britannica.bec.de>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: pkg/38066 (tar doesn't dearchive correctly long symlinks)
Date: Tue, 20 May 2008 14:38:08 +0200

 On Tue, May 20, 2008 at 12:15:05PM +0000, Mihai Chelaru wrote:
 >  Problem is still alive with pkgtoos/pkg_install in pkg_install-renovation 
 >  branch from today.

 I've tested this with the current version and mono-1.9.1nb1 as it can be
 found under
 http://ftp.netbsd.org/pub/pkgsrc/packages/NetBSD/x86_64/4.99.x/

 pkg_add handles all links correctly here. tar/pax still have the issue,
 of course. Are you sure you are using the right version of pkg_add?

 Joerg

From: Mihai Chelaru <kefren@ngnetworks.ro>
To: gnats-bugs@netbsd.org
Cc: joerg@netbsd.org,
 gnats-admin@netbsd.org,
 pkgsrc-bugs@netbsd.org
Subject: Re: pkg/38066 (tar doesn't dearchive correctly long symlinks)
Date: Tue, 20 May 2008 16:40:25 +0300

 Sorry, I was still using old pkg_add by mistake. The one in 
 pkg_install-renovation branch works as expected. Links are created correctly.

State-Changed-From-To: feedback->analyzed
State-Changed-By: joerg@NetBSD.org
State-Changed-When: Sat, 11 Oct 2008 21:57:37 +0000
State-Changed-Why:
Feedback was provided, problem is understood.


State-Changed-From-To: analyzed->closed
State-Changed-By: dholland@NetBSD.org
State-Changed-When: Sat, 01 Aug 2009 19:54:47 +0000
State-Changed-Why:
The pkg_install-renovation branch was merged, so this should be fixed.


State-Changed-From-To: closed->analyzed
State-Changed-By: joerg@NetBSD.org
State-Changed-When: Sun, 02 Aug 2009 02:00:30 +0000
State-Changed-Why:
Reopen, the problem for tar itself is still present.


>Unformatted:

Home	PR Database Search