Re: 'cp -lL' behaviour conflicts with documentation

[Tim Waugh]

On Tue, Mar 15, 2005 at 04:38:03PM +0100, Jim Meyering wrote:

> Tim Waugh <address@hidden> wrote:
> > coreutils-5.2.1:
> >
> > $ mkdir /tmp/foo
> > $ cp -lL /lib/libc.so.6 /tmp/foo
> > $ ls -l /tmp/foo
> > total 4
> > lrwxrwxrwx  2 root root 13 Mar  8 10:59 libc.so.6 -> libc-2.3.4.so
> >
> > The man page says that -L always dereferences symbolic links, but when
> > used in conjuction with -l (link files instead of copying) this is not
> > honoured.
> >
> > (Originally RH bug #150951.)
> 
> Thanks for the report.
> I suppose this is a documentation bug, since
> making hard links to symlinks is not portable.
> I suppose -L and -l should mention that when they are used
> together, cp may try to make hard links to symbolic links.

It isn't obvious to me that a hardlink to a symbolic link would be
created.  Why isn't a hard link to the referent created?

The --help output says:

  -L, --dereference            always follow symbolic links

so it's quite surprising that an operation occurs on the link itself
rather than the referent, regardless of whether the operation is to
copy or to make a hard link to.

Surely the non-portability of making hard links to symlinks would only
occur if -L was _omitted_ from the argument list?

Tim.
*/

pgpGScX9ogRSr.pgp
Description: PGP signature