GNU bug report logs - #17103
cp: "cp -al" doesn't copy symlinks, tries to link to them

Previous Next

Full log

Message #74 received at 17103 <at> debbugs.gnu.org (full text, mbox):

From: Linda Walsh <coreutils <at> tlinx.org>
To: Pádraig Brady <P <at> draigBrady.com>
Cc: 17103 <at> debbugs.gnu.org, Paul Eggert <eggert <at> cs.ucla.edu>,
 Eric Blake <eblake <at> redhat.com>
Subject: Re: bug#17103: regression: cp -al doesn't copy symlinks,
 but tries to link to them (fail)
Date: Thu, 27 Mar 2014 10:59:49 -0700

Pádraig Brady wrote:
> On 03/27/2014 02:10 PM, Linda Walsh wrote:
>> But those are separate for how cp should behave on filesystems with varying,
>> "assumed" capabilities...(i.e. failing because one can't link to a symlink
>> when linking to symlinks isn't a requirement for this to be allowed on
>> systems that don't support symlinking at all).  I.e. as it stands, the ability
>> to hardlink to a file is dependent on what features and policies your
>> kernel has built in.  Cp should work as well as possible regardless of
>> those policies.
> 
> Agreed, but :)
> 
> Old systems that didn't support hardlinks to symlinks, would not depend
> on that functionality, and thus the workaround of creating new symlinks is OK.
> 
> Going forward, all systems will support hardlinks to symlinks
> and those systems might rely on that functionality.
----
	The above statement is no longer true on linux with
the new feature -- which is enabled by default (I find nothing under
'/etc/' that would change or references 'protected_' other
than some reference where it is in an ENV string, but nothing sets it
to 'on' @ boot.  I'll have to reboot my machine to find out for sure as
it's been up for 26 days....  but will **likely be out for the rest
of the day**.  Since some distro's are shipping it that way by default now,
the above statement doesn't always apply on linux-based systems.



> This is my main concern with the fall back.  The inconsistency
> concern (with not also handling setuid files or fifos etc.) is
> valid also, but secondary as it's less likely and shouldn't
> cause a logic issue like above.
---
	The above wouldn't work on a linux system 3 years ago
if the fs they ran that on was on a windows type file system
 -- an esoteric case, but possible -- It's not a very portable
construct to begin with.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.