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

[Pádraig Brady]

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.

Consider:

  while sleep 1d; do
    find source/ -links 1 | process_new_files_or_links
    cp -al source/ snap_$(date +%s)/ || break
  done

If cp -al silently created symlinks as a fall back, then the above
would continue to erroneously process existing symlinks.
This could happen if an existing script is copied to a new system
with /proc/sys/fs/protected_hardlinks enabled.
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.

Maybe the above case is a bit esoteric, but logic wise it's sound.
Also this whole issue is a _little_ unusual anyway because usually
it's the root user doing the cp -al, or the owner of source/

Ideally the solution to this would be to adjust the symlinks in source/
in such a way that one could hardlink them, or otherwise relax this
restriction in the kernel.  That would be preferable as it would
be available for all applications rather than placing possibly
problematic workarounds in a single program.

thanks,
Pádraig.