Bug 1054638

Summary:	Extracting single files does not work
Product:	[Fedora] Fedora	Reporter:	Fabian Deutsch <fdeutsch>
Component:	cpio	Assignee:	Ondrej Vasik <ovasik>
Status:	CLOSED NOTABUG	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	19	CC:	kdudka, ovasik, praiskup
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2014-01-17 07:51:38 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Fabian Deutsch 2014-01-17 07:34:17 UTC

Description of problem:
According to http://www.rpm.org/max-rpm/s1-rpm-miscellania-rpm2cpio.html , cpio should be capable of extracting single files from a cpio archive, but the example iven doesn't work.

Version-Release number of selected component (if applicable):
$ rpm -qf $(which cpio)
cpio-2.11-21.fc19.x86_64

How reproducible:
Alwas

Steps to Reproduce:
1. Run:
rpmls http://ovirt.org/releases/ovirt-release-el.noarch.rpm

2. Run
$ rpm2cpio http://ovirt.org/releases/ovirt-release-el.noarch.rpm | cpio -ivd etc/yum.repos.d/glusterfs-epel.repo
28 blocks

3. Run
$ rpm2cpio http://ovirt.org/releases/ovirt-release-el.noarch.rpm | cpio -ivd /etc/yum.repos.d/glusterfs-epel.repo  (leading /)
28 blocks

Actual results:
After 1. No file is extracted
After 2. No file is extracted

Expected results:
The selected file get's extracted

Additional info:

Comment 1 Fabian Deutsch 2014-01-17 07:36:39 UTC

It seems to work if I append a leading "." to the path to be extracted:

$ rpm2cpio http://ovirt.org/releases/ovirt-release-el.noarch.rpm | cpio --to-stdout -iv ./etc/yum.repos.d/glusterfs-epel.repo
# Place this file in your /etc/yum.repos.d/ directory

[glusterfs-epel]
name=GlusterFS is a clustered file-system capable of scaling to several petabytes.
baseurl=http://download.gluster.org/pub/gluster/glusterfs/LATEST/EPEL.repo/epel-$releasever/$basearch/
....


It could be the correct behavior (as rpmls also showed the leading dot)

Comment 2 Pavel Raiskup 2014-01-17 07:51:38 UTC

Thanks for the report.  That is most probably problem in rpmls.

Try the rpm2cpio (or extract the CONTENTS.cpio other way) and then try to 
look for the archive contents.  E.g. cat CONTENTS.cpio | cpio -t

That shows you that the files are not stored absolutely inside.

Comment 3 Pavel Raiskup 2014-01-17 09:03:53 UTC

Ok, I missed the point what is exactly a problem because we have probably
a little bit different rpmls versions (my is not showing leading dot):

  $ rpmls ovirt-release-el.noarch.rpm
  -rw-r--r--  /etc/yum.repos.d/el6-ovirt.repo
  -rw-r--r--  /etc/yum.repos.d/glusterfs-epel.repo
  drwxr-xr-x  /usr/share/doc/ovirt-release-el6-10
  -rw-r--r--  /usr/share/doc/ovirt-release-el6-10/ASL

But the content is:

  $ rpm2cpio ovirt-release-el.noarch.rpm | cpio -t
  ./etc/yum.repos.d/el6-ovirt.repo
  ./etc/yum.repos.d/glusterfs-epel.repo
  ./usr/share/doc/ovirt-release-el6-10
  ./usr/share/doc/ovirt-release-el6-10/ASL

---

You want to make the './xx' be equivalent of 'xx' (in both archive contents and
parameters).  So far, all archivers I am aware of distinguish between those
patterns inside archive.  Just libarchive (bsdtar) takes those patterns in
arguments equivalently (but usual case is to compare verbatim):

  $ bsdtar -cf a.tar a ./a

  $ bsdtar -tf a.tar
  a/
  a/b/
  a/b/c
  ./a/
  ./a/b/
  ./a/b/c

  $ bsdtar -tf a.tar a/b/c
  a/b/c
  ./a/b/c

  $ bsdtar -tf a.tar ./a/b/c
  a/b/c
  ./a/b/c

But, for GNU cpio (same upstream as GNU tar), this is imo NOTABUG.  Verbatim
comparison was always there.  And in GNU tar that is also documented as
wanted (2.7 How to List Archives).  But I'll rather ask upstream.

Pavel