Bug 1044801 - cp -rl behavior changed in regards to symlinks with 8.22
Summary: cp -rl behavior changed in regards to symlinks with 8.22
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: coreutils
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Ondrej Vasik
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-12-19 03:25 UTC by Josh Boyer
Modified: 2013-12-19 15:39 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-12-19 07:16:35 UTC
Type: Bug


Attachments (Terms of Use)

Description Josh Boyer 2013-12-19 03:25:18 UTC
Description of problem:

Starting with today's rawhide, the kernel builds have been failing.  Looking at the failure lead to something that didn't quite make sense, in that it was saying an file that should exist doesn't.  After poking around a bit, I noticed that during the prep for kernel.spec, we're copying the vanilla sources before patching, and that changes a relative symlink in the source into a directory of the contents of the link in the destination.  This is most easily seen here:

<mock-chroot>[root@vader kernel-3.12.fc21]# ls -l vanilla-3.12/arch/arm/boot/dts/include/
total 0
lrwxrwxrwx. 1 root root 34 Nov  3 18:41 dt-bindings -> ../../../../../include/dt-bindings
<mock-chroot>[root@vader kernel-3.12.fc21]# cp -rl vanilla-3.12 vanilla-3.13
<mock-chroot>[root@vader kernel-3.12.fc21]# ls -l vanilla-3.13/arch/arm/boot/dts/include/
total 4
drwxr-xr-x. 11 root root 4096 Dec 18 22:18 dt-bindings
<mock-chroot>[root@vader kernel-3.12.fc21]# 

This then leads to weird patch behavior not creating the file the build expects, but not presenting an error either.

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

<mock-chroot>[root@vader kernel-3.12.fc21]# rpm -q coreutils
coreutils-8.22-1.fc21.x86_64
<mock-chroot>[root@vader kernel-3.12.fc21]# 

How reproducible:

Always thus far.  2 real builds and 1 scratch with coreutils-8.22-1.fc21 and testing in a mock chroot with that all seem to recreate this behavior.

Steps to Reproduce:
1.  Untar something with a symlink in it
2.  cp -rl <source> <dest>
3.

Actual results:

symlink in <source> is replaced by a copy of the contents in <dest>

Expected results:

Previous coreutils-8.21 behavior preserved the symlink:

[jwboyer@zod kernel-3.12.fc21]$ ls -l vanilla-3.12/arch/arm/boot/dts/include/
total 0
lrwxrwxrwx. 5 jwboyer jwboyer 34 Nov  3 18:41 dt-bindings -> ../../../../../include/dt-bindings
[jwboyer@zod kernel-3.12.fc21]$ cp -rl vanilla-3.12 vanilla-3.13
[jwboyer@zod kernel-3.12.fc21]$ ls -l vanilla-3.13/arch/arm/boot/dts/include/
total 0
lrwxrwxrwx. 6 jwboyer jwboyer 34 Nov  3 18:41 dt-bindings -> ../../../../../include/dt-bindings
[jwboyer@zod kernel-3.12.fc21]$ rpm -q coreutils
coreutils-8.21-18.fc20.x86_64
[jwboyer@zod kernel-3.12.fc21]$ 

Additional info:

I have no idea if this behavior change is expected or not.  I also noticed that if I specify 'cp -rdl' it preserves the symlink and that works for both coreutils-8.21 and coreutils-8.22.  I opened the bug because I have no clue on the change, and because other packages might hit similar issues.

Thoughts?

Comment 1 Pádraig Brady 2013-12-19 04:15:17 UTC
So this is expected in coreutils-8.22
Gory details here: http://bugs.gnu.org/15173

The summary is that the old behavior was inconsistent.
Also `cp -al` is the most common way to create a hard linked tree,
and being explicit in its dereferencing behavior,
is unimpacted by the change.

Comment 2 Pádraig Brady 2013-12-19 04:28:27 UTC
BTW this `cp -rl` usage looks quite retricted:
https://www.google.com/search?q=site:pkgs.fedoraproject.org+"cp+-rl"

Comment 3 Ondrej Vasik 2013-12-19 07:16:35 UTC
Closing NOTABUG based on Pádraig's explanation.

Comment 4 Ondrej Vasik 2013-12-19 15:11:00 UTC
Adding phracek to cc, as bacula is the second affected component based on padraig's investigation.


Note You need to log in before you can comment on or make changes to this bug.