Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 145225 - [PATCH] cpio does not pack symlinks properly
Summary: [PATCH] cpio does not pack symlinks properly
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: cpio
Version: rawhide
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Peter Vrabec
QA Contact: Brock Organ
URL:
Whiteboard:
Depends On:
Blocks: FC4Blocker
TreeView+ depends on / blocked
 
Reported: 2005-01-15 17:03 UTC by Ralf Ertzinger
Modified: 2007-11-30 22:10 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2005-01-17 11:22:32 UTC
Type: ---
Embargoed:

Attachments (Terms of Use)
My patch. Could not find that one from upstream (deleted)
2005-01-17 11:21 UTC, Peter Vrabec 		no flags Details
View All

Description Ralf Ertzinger 2005-01-15 17:03:28 UTC 
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5)
Gecko/20041228 Firefox/1.0 Fedora/1.0-8

Description of problem:
cpio automatically dereferences symlinks while packing (as if the
option -L was passed, although it is not:

[sun@nausicaa ~/initrd :) 50]$ gunzip -c
/boot/initrd-2.6.10-1.1087_FC4.img | cpio -id
cpio: dev/systty: Operation not permitted
cpio: dev/console: Operation not permitted
cpio: dev/ram: Operation not permitted
cpio: dev/tty4: Operation not permitted
cpio: dev/null: Operation not permitted
cpio: dev/tty2: Operation not permitted
cpio: dev/tty3: Operation not permitted
cpio: dev/tty1: Operation not permitted
3798 blocks
[sun@nausicaa ~/initrd :) 51]$ find -type l
./bin/hotplug
./bin/modprobe
./bin/udevstart
./sbin
[sun@nausicaa ~/initrd :) 52]$ find . | cpio -c -o > ../initrd.img
6456 blocks
[sun@nausicaa ~/initrd :) 53]$ rm -rf *
[sun@nausicaa ~/initrd :) 54]$ cpio -id < ../initrd.img 
6456 blocks
[sun@nausicaa ~/initrd :) 55]$ find -type l
[sun@nausicaa ~/initrd :) 56]$

As can be seen, the symlinks are being dereferenced while packing.

Version-Release number of selected component (if applicable):
cpio-2.6-2

How reproducible:
Always

Steps to Reproduce:
1. Pack a file structure with symlinks (without -L)
2. Unpack it
3.
    

Actual Results:  Symlinks are being dereferenced

Expected Results:  No dereferencing unless requested

Additional info:
Comment 1 Tom London 2005-01-15 20:04:40 UTC 
Backing up to cpio-2.5-9 works around this problem...sigh
Comment 2 Sammy 2005-01-16 01:30:53 UTC 
The effect is even bigger when you pack/unpack (mkinitd) the kernel. 
Since the symlinks are not created you end with a empty /sbin for 
the initrd image and bunch of error messages during boot. Going 
back to 2.5-9 solves the problem too.
Comment 3 Paul Iadonisi 2005-01-16 06:12:02 UTC 
Dang, what a pain this was to track down.  I'm no expert with autotools, but if
you're using HAVE_* #define's, don't those have to be generated by your
configure script and set in config.h or something like that?

Take a look at lib/system.h and you'll see a '#define lstat stat' line that's
wrapped with a '#if !HAVE_LSTAT ...'  block, but I can't see anywhere in the
entire source tree where lstat is actually being checked for and HAVE_LSTAT
subsequently being set.  This code didn't exist in cpio-2.5.

Frankly, this looks like half finished code.  Not sure what the best fix is
other than just deleting that '#if' block altogether (I tried it and it does
work, at least for i386).
Comment 4 Marcin Garski 2005-01-16 16:32:06 UTC 
Please look at:
http://lists.gnu.org/archive/html/bug-cpio/2005-01/msg00003.html

The bug has been fixed upstream.
Comment 5 Peter Vrabec 2005-01-17 11:21:43 UTC 
Created attachment 109859 [details]
My patch. Could not find that one from upstream
Note You need to log in before you can comment on or make changes to this bug.