Re: Short circuit cp -l

[D'Arcy Cain <darcy%NetBSD.org@localhost>]

On 2018-07-18 02:11 AM, Robert Elz wrote:
> You do understand though that you have changed the semantics?  The
> old way, cp -l would only link the files that could have been copied, now
> it will happily link unreadable files.   Also cp -il will no longer work, and
> probably more.

I missed that.  I don't see the first as being an issue.  The second
isn't an issue for me but it might be for others.  However, since this
is a non-standard option I suppose we can define it as we like.  I am
not sure what Linux does.  The only other implementation is in OpenBSD
and I know that they copied my code so perhaps they will also copy this
change.  A 10X speedup is nothing to ignore lightly.

> With this change, I don't really know why the option needs to exist at
> all, cp -l seems to be just a defective implementation of ln -f .. I'd be 

I think at the time I considered adding a -r option to ln instead but
adding -l to cp was a lot less intrusive.

The point, for me at least, of this option is to allow an exact, hard
linked copy of a directory to be created for incremental backups so I
always use it with "-r".  The workflow is rsync to a backup directory,
possibly from a remote machine and then make a hard link copy.  The next
day the rsync will copy over any changed files and the hard link copy
will back them up incrementally.  Something like "pax -rwl" but faster.

Maybe I just need a stand-alone utility.

> inclined to simply delete the -l option (or simply exec "ln" when the -l
> option is given to cp, if there is some good reason for having a -l option).

I certainly wouldn't want to exec something for every file.

-- 
D'Arcy J.M. Cain <darcy%NetBSD.org@localhost>
http://www.NetBSD.org/ IM:darcy%Vex.Net@localhost