Subject: Re: bug#17103: regression: cp -al doesn't copy symlinks, but tries to link to them (fail)

From: Linda Walsh <[email-masked]>
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.