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

Previous Next

Package: coreutils;

Reported by: Linda Walsh <coreutils <at> tlinx.org>

Date: Wed, 26 Mar 2014 18:09:01 UTC

Severity: normal

Full log


View this message in rfc822 format

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: 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.






This bug report was last modified 6 years and 157 days ago.

Previous Next


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