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

[Linda Walsh]

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.