Red Hat Bugzilla – Bug 614676
Beta 2 cpio no longer handles symbolic links to directories
Last modified: 2010-07-22 02:01:01 EDT
Description of problem: If I create a cpio archive containing symbolic links to directories, extracting the archive results in the links being replaced with empty directories. This occurs using the -o and -p options. If I replace the beta 2 cpio with beta 1 cpio it works correctly. Version-Release number of selected component (if applicable): cpio-2.10-8.el6.x86_64.rpm How reproducible: Always fails Steps to Reproduce: 1. Create a /tmp/iso directory. 2. Mount the beta 2 iso on /mnt using the -o loop option 3. Change directory to /mnt and run 'find . -print | cpio -pdvm /tmp/iso' 4. Look at the repodata directory - was a symbolic link to Server/repodata, now is an empty directory. Actual results: Expected results: Additional info:
Thanks for report - could you please where is the symlink in iso pointing (ls -l <symlinkaddress> or readlink <symlinkaddress> ? Maybe it is dangling symlink after the copy. If you just downgrade to beta1 cpio rpm, does it work correctly? If so, could you please attach strace of both runs (if you manage to get some more minimalistic fail scenario, it would be better) ? I don't think there was any change to the symlink handling between beta1 and beta2 cpio, but everything is possible. Do you have some smaller reproducer? I tried: $ mkdir tmp $ cd tmp $ dd if=/dev/zero of=blob bs=8192 count=200 $ mkdir mnt $ mkfs -t ext2 -F blob $ sudo mount -oloop blob mnt $ mkdir -p x/y $ touch x/y/a $ ln -s x/y c $ cd mnt $ find . -print | cpio -pdvm ../cpio.archive and it just worked (and directory symlinks were copied correctly) - so I think some special circumstances are necessary to reproduce the issue.
I was running this on a KVM virtual machine. I just tried this with the beta 2 refresh version of cpio and it works fine.
Thanks for retesting... Strange, there was no cpio update between beta 2 and beta 2 refresh - so I guess the problem itself is likely not in cpio directly - maybe kernel or some library update affected it. Without clear reproducer and strace is everything very uncertain, so closing this bugzilla as "not a bug" - feel free to reopen it if you'll get some usable reproducer(and/or strace of the failure) in future. TIA.